architecture - 扩展方法的使用——这不是糟糕的设计吗？

Question

我刚刚开始研究 .NET 3.5，所以如果之前有人问过这类问题，请原谅我。我正在为扩展方法的体面使用而苦苦挣扎，因为我刚刚下载了 suteki shop 一个 MVC 电子商务产品。在这个项目中，有一个非常标准的存储库模式，它扩展了 IRepository。

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

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

现在这一切都很好，但是就我而言，接口(interface)充当实现它们的对象的契约。

存储库已被接口(interface)的事实表明尝试采用与数据层无关的方法。也就是说，如果我要创建自己的数据层，我会很困惑我必须创建哪些扩展方法来确保我已经满足了对实现我的存储库类的类的契约(Contract)要求。

似乎创建 IRepository 然后扩展的旧方法可以更好地了解所需内容，例如

ICategoryRepoitory : IRepository<Category>
{
     Category GetRootCategory();
}

所以我想我的问题是这种使用扩展方法对其他人来说似乎是错误的吗？如果不是，为什么？我不应该为此提示吗？

编辑:

上面的例子似乎是一个很好的例子，说明了为什么扩展方法非常有用。

我想我的问题是数据访问特定实现是否卡在数据访问机制程序集中的扩展方法中。

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

Answer 1

关键是如果你已经实现了所有 IRepository<T>适本地，您(作为数据层实现者)根本不必了解根类别。对于此扩展方法的范围，假设任何类别的存储库都将具有 ID 1 的根类别。这可能是一个完全合理的假设，也是一个有用的假设:没有人必须构建派生类(它可能是不切实际的——数据层可能有工厂等，这使得从实现中派生变得很棘手)。

现在，扩展方法仅在其范围合适的情况下才适用 - 如果它位于 namespace (或密切相关的 namespace )中，关于根类别的假设将是有效的。

我不认为“较旧”的方式真的是扩展 IRepository<Category> 的接口(interface)。 - 这将是一个正常的静态方法，采用 IRepository<Category> .这就是扩展方法让生活更愉快的地方。如果您真的会使用继承，那么现在也可以这样做。不幸的是，我们对您的系统架构的了解还不够，无法肯定地说。