1

我正试图围绕 IoC 容器。当我深入研究这种设计模式时，我遇到了许多抽象层、接口和具体类，而之前我只是实例化一个数据上下文类，使用它然后处理它。

虽然我很想继续前进，但仍有一些悬而未决的问题我不知道如何解决，希望得到一些澄清和指导。

  1. 在具有 2 个项目（包含 ef 的 mvc web 和数据层）的通用 Web 应用程序中，如果我们的依赖解析器需要一个实现特定接口的存储库（允许我们将来随时切换存储库），那么这个接口在哪里定义？我看不到它是如何在 mvc web 项目中定义的，因为这样数据访问层将依赖于它，并且它不能驻留在数据访问层中，因为 mvc 项目依赖于 dal，我错过了整点这个练习的。那么在两个项目中定义它并让每个项目引用自己的副本的答案是什么？..这甚至可能吗？还是我需要创建第三个服务层项目并在其中粘贴一个接口声明并让两个项目都引用它？

  2. 我看过很多文章谈论 Unity IoC 的接口，例如 IProductRepository、IClientRepository 和 IProductService、IClientService（这是我在开头段落中提到的）。假设这些实例中的每一个都应该引用我的数据库中的一个表，我是否正确？如果是这样，如果我有 50 张桌子会发生什么？我是否需要创建 50 个存储库接口和 50 个与表相关的接口来解耦所有内容？以及将 EF 与 POCO 类一起使用会如何影响事物？我需要让每个 POCO 实现自己指定的接口吗？

谢谢

4

2 回答 2

0

理想情况下，您会将解决方案拆分为多个项目。

您将有一个合同项目，其中定义了您的接口，一个实现了这些接口的具体版本的 dal。

然后，您的 mvc 项目将引用contracts 项目来处理对类型的引用。

您将使用 IOC 容器扫描 bin 文件夹中的程序集，并为您的控制器找到依赖项的具体实现。这意味着您会将 dal 构建到 mvc 项目的 bin 文件夹中。这意味着您只需在 bin 文件夹中放置一个新的 dll 即可将 dal 切换为其他实现。

至于存储库和表，我倾向于按业务功能对它们进行分组。因此，管理用户及其相关表的业务功能将在用户存储库等中，但这取决于个人喜好 imo。

于 2013-03-25T11:58:31.303 回答
0

当您将项目分成几层时，您不希望您的数据层依赖于堆栈中更靠前的项目是正确的。通常，您希望这些依赖项是单向的。您可以继续您正在做的事情并将接口放在数据层中，或者您可以创建一个新项目来容纳模型代码，包括存储库和服务接口。您的数据层将取决于模型代码，而您的 mvc 层将取决于数据层。

为了解决您的第二个问题，我想说这就是设计艺术的用武之地。您不一定想要实体和数据表之间的一对一映射。如果它有意义并且您认为它是可管理的，尤其是在实体框架的帮助下，那么继续进行一对一映射。但请记住，持久层和领域模型层的职责是不同的。如果持久层开始阻碍您创建领域模型的工作，那么是时候投入一些工作来将两者分开了。

更重要的是要暴露给 mvc 项目的接口“外观”。这些将需要与模型层和持久层进行某种程度的解耦。它们应该被提炼为模型的核心职责。你不想让你的应用层被复杂的领域模型弄得一团糟。

于 2013-03-25T12:24:16.163 回答