我试图围绕IoC容器。当我深入研究这种设计模式时，在我简单地实例化数据上下文类，使用它然后处理它之前，我遇到了大量的抽象层，接口和具体类。
虽然我渴望继续前进，但仍有一些我不知道如何解决的突出问题，并希望得到一些澄清和指导。
在具有2个项目的通用Web应用程序中（mvc web＆amp; data layer 包含e.f.），如果我们的依赖解析器需要一个存储库 实现特定的接口（允许我们切换 存储库在将来的任何时间），这个接口在哪里 界定？我没看到它是如何在mvc web项目中定义的，因为那时数据访问层将依赖于它并且它不能驻留在数据访问层中，因为mvc项目依赖于dal并且我错过了整点这个练习。也是 在两个项目中定义它并拥有每个项目的答案 参考自己的副本？ ..那甚至可能吗？或者我需要 创建第三个服务层项目并坚持一个界面 在其中声明并让两个项目都参考这个？
我见过很多关于Unity IoC的文章 接口，如IProductRepository，IClientRepository和 IProductService，IClientService（这就是我所指的 我的开头段落）。我是否正确地假设每一个 实例应该引用我的数据库中的表？如果是这样 如果我有50张桌子怎么办？我需要创建50个存储库吗？ 接口和50个表相关的接口只是为了解耦所有东西？ 使用EF与POCO课程如何影响事物？我需要吗？ 让每个POCO实现自己指定的接口吗？
感谢
答案 0 :(得分：0)
理想情况下，您可以将解决方案分成几个项目。
您将拥有一个合同项目，其中定义了您的接口，这是一个dal，其中实现了这些接口的具体版本。
然后，您的mvc项目将引用合同项目来处理对类型的引用。
您将使用IOC容器扫描bin文件夹中的程序集，并找到控制器的依赖项的具体实现。这意味着您将dal构建到mvc项目的bin文件夹中。这意味着只需在bin文件夹中放置一个新的dll即可将dal切换为其他实现。
至于存储库和表，我倾向于按业务功能对它们进行分组。因此，管理用户及其相关表的业务功能将位于用户存储库等中，但这取决于个人偏好imo。
答案 1 :(得分：0)
当您将项目分成几层时，您不希望数据层依赖于堆栈中的项目。通常，您希望这些依赖项是单向的。您可以继续执行您正在执行的操作并将接口放在数据层中，也可以创建一个新项目来容纳模型代码，包括存储库和服务接口。您的数据层将取决于型号代码，您的mvc层将取决于数据层。
为了解决你的第二个问题，我想说这就是设计艺术的用武之地。你不一定要在实体和数据表之间进行一对一的映射。如果它有意义并且您认为它是可管理的，特别是在Entity Framework的帮助下，那么继续进行一对一映射。但请记住，持久层和域模型层的职责是不同的。如果持久层开始陷入创建域模型的工作，那么是时候将一些工作分开来了。
更重要的是接口'外观'将暴露给mvc项目。这些将需要与模型和持久层进行某种程度的分离。它们应该被提炼为模型的核心职责。您不希望使用域模型的复杂性来混淆应用程序层。