给定一个代码项目，它应该通过实现松散耦合的层，具有IoC容器等来遵守SoC原则，例如，一个简单的ASP.NET MVC解决方案，它被分成以下程序集：
并且 Model 程序集中的具体存储库必须实现一个公共接口IMyBusinessRepository，在哪个程序集中你会放置该接口？
1）如果你将该接口放在 Model 程序集中，很可能在不修改代码的情况下用另一个程序集替换该程序集是不可能的（至少如果它有不同的命名空间） 应用程序程序集。此外，驻留在不同程序集中的替代IMyBusinessRepository实现必须引用原始的（Argh！）
2）如果将它放在 Application 程序集中，则无法在不引用 Application Model 程序集>集会（唉！）
3）或者您是否会为该接口创建一个单独的通用程序集，对于每个通用接口或一组接口？ （哎呀？）
总而言之， X 程序集应该可以在应用程序 A 中轻松替换（仅通过更改引用），并且可以在应用程序 B 中重用， C ， D 。
答案 0 :(得分：2)
您可以按照建议简单地使用“合同”或“接口”程序集。
但是，考虑到您正在尝试处理关注点主体的分离，您是否希望同时替换所有接口的所有实现，或者可能只是一个具体的实现。
如果您希望替换all，则单独的程序集可能是最佳的，否则您可以简单地将Model程序集中的替换实现与现有实现一起使用，并且接口也在Model程序集中声明。
答案 1 :(得分：2)
选项3.
将接口定义放入调用代码中就可以了，直到您想要针对接口进行开发而不是持有它的组件（比如你想要构建一个数据访问提供者，但你不想引入整个网站项目）。把它与实现放在一起只是疯狂的谈话：）
您是否会为该接口创建一个单独的通用程序集，对于每个通用接口或一组接口？ （哎呀？）
我会通过考虑Commom Closure和Common Reuse原则将接口分组到单独的程序集中。通过独立他们也将more stable。考虑一下它们将被使用的场景 - 将它们保持在一起是否有意义 - 如果是这样的话，那么它们在一个组件中就可以了。
答案 2 :(得分：2)
我建议将接口放在单独的程序集中，或者在同一程序集中接近它们的实现。接口应始终至少有一个实现以及接口本身。常见的方法是将接口放在同一个程序集中的单独文件夹下。
答案 3 :(得分：0)
发现了一个类似的问题：Loose Coupling of Components
答案 4 :(得分：-1)
SoC是一个逻辑概念，您试图将其转换为物理概念。
将您的存储库放入模型中的唯一不利影响是，将来可能很难交换程序集。我不明白这个问题？也许外星人会入侵，我们需要把银河时间放在我们的数据库中。我们现在应该编码那个抽象吗？可能不是。
我也不理解这个问题。什么阻止你在模型程序集中使用Concrete1 : IRepository和Concrete2 : IRepository？
如果您的应用程序的核心需要通过模型类中的更改来修改，那么您可能也会错误地耦合。有点倒退了。