1

给定一个代码项目，它应该通过实现松散耦合的层、具有 IoC 容器等来遵守 SoC 原则，例如，一个简单的 ASP.NET MVC 解决方案，它分为以下程序集：

  • 应用程序集+命名空间
  • 模型组件+命名空间（包含访问数据库数据的具体存储库）

以及模型程序集中的具体存储库必须在哪里实现一个通用接口IMyBusinessRepository，你会将那个接口放在哪个程序集中？

1) 如果您将该接口放入模型程序集中，那么如果不修改应用程序程序集的代码，就不可能用另一个程序集替换该程序集（至少如果它具有不同的命名空间）。此外，驻留在不同程序集中的替代 IMyBusinessRepository实现必须引用原始程序集（Argh！）

2）如果你把它放在Application程序集中，如果不引用Application程序集，就不可能在其他项目中使用Model程序集（Argh！）

3) 或者您会为该接口创建一个单独的通用程序集，并且就此而言，为每个通用接口或一组接口创建一个单独的通用程序集？（啊？）

总而言之，X组件应该可以在应用程序A中轻松替换（仅通过更改引用），并且可以在应用程序B、C、D中重用。

4

4 回答 4

2

正如您所建议的，您可以简单地使用 Contracts 或 Interfaces 程序集。

但是，考虑到您正在尝试使用关注点分离原则，您是否希望同时替换所有接口的所有实现，或者可能只是一个单一的具体实现。

如果您希望全部替换，则最好使用单独的程序集，否则您可以简单地将模型程序集中的替换实现与现有实现一起替换，并且接口也在模型程序集中声明。

于 2011-02-20T05:50:58.263 回答
2

选项 3。

将接口定义与调用代码一起放入是很好的，直到您想要针对接口而不是持有它的组件进行开发（假设您想要构建一个数据访问提供程序但您不想拉入整个网站项目）。把它和一个实现放在一起只是疯狂的谈话:)

您是否会仅为该接口创建一个单独的通用程序集，并且就此而言，为每个通用接口或一组接口创建一个单独的通用程序集？（啊？）

我会通过考虑Commom Closure和Common Reuse原则将接口分组到单独的程序集中。通过独立，他们也会更加稳定。考虑将使用它们的场景 - 将它们放在一起是否有意义 - 如果是这样，那么它们在一个组件中可能没问题。

于 2011-02-21T06:56:30.643 回答
2

我建议将接口放在单独的程序集中或接近它们在同一程序集中的实现。接口本身应该至少有一个接口实现。常见的方法是将接口放在同一个程序集中的单独文件夹下。

于 2011-03-14T10:18:38.300 回答
-1

SoC 是一个逻辑概念，您试图将其转化为物理概念。

将存储库放入模型中的唯一不利影响是程序集，可能在未来可能很难交换程序集。我不明白这种担心？也许外星人会入侵，我们需要将银河时间放入我们的数据库中。我们现在应该编码那个抽象吗？可能不是。

我也不明白这种担心。是什么阻止您拥有Concrete1 : IRepository和Concrete2 : IRepository在模型程序集中？

此外，如果您的应用程序的核心需要通过更改模型类来修改，您可能会错误地耦合某些东西。这有点倒退。

于 2011-02-20T06:44:37.200 回答