扩展方法的用法 - 这不是一个糟糕的设计吗？

我刚刚开始研究.NET 3.5,如果之前已经提出这类问题,请原谅我.我正在努力使用扩展方法,因为我刚刚下载了suteki商店的MVC电子商务产品.在这个项目中,有一个非常标准的Repository模式,它扩展了IRepository.

为了扩展此接口公开的基本功能,使用了扩展方法,即:

public static class CategoryRepositoryExtensions
{
    public static Category GetRootCategory(this IRepository categoryRepository)
    {
     return categoryRepository.GetById(1);
    }
}

现在这一切都很好,但就我而言,Interfaces充当了实现它们的对象的契约.

存储库已经接口的事实表明尝试采用数据层不可知的方法.也就是说,如果我要创建自己的数据层,我会对我必须创建的扩展方法感到困惑,以确保我已经完成了对实现我的存储库类的类的合同要求.

似乎创建IRepository然后扩展的旧方法允许更好地查看所需内容,例如

ICategoryRepoitory : IRepository
{
     Category GetRootCategory();
}

所以我想我的问题是,对于其他人来说,这种扩展方法的使用是否是错误的？如果没有,为什么？我不应该抱怨这个吗？

编辑:

上面的例子似乎是一个很好的例子,说明为什么扩展方法可以非常有用.

我想我的问题是,如果数据访问特定的实现被卡在数据访问机制程序集中的扩展方法中.

这样,如果我将其换成另一种机制,我将不得不在该程序集中创建一个类似的扩展方法.

关键是如果你已经IRepository适当地实现了所有,你(作为数据层实现者)根本不必知道根类别.对于此扩展方法的范围,假设任何类别的存储库都将具有ID 1的根类别.这可能是一个完全合理的假设,并且是一个有用的假设:没有人必须构建派生类(其中可能是不切实际的 - 数据层可能有工厂等,这使得从实现中派生出来很棘手).

现在,扩展方法仅适用于其范围适当的情况 - 如果它位于命名空间(或密切相关的范围)中,其中关于根类别的假设将是有效的.

我不认为"较旧"的方式实际上是一个扩展的接口IRepository- 这将是一个正常的静态方法IRepository.这就是扩展方法让生活更愉快的地方.如果你真的会使用继承,那么现在也可以这样做.不幸的是,我们对你的系统架构知之甚少.