服务、模型和存储库层之间的交互

Question

我的任务是将应用程序从 SharePoint 转换为 .NET。我关心以正确的方式做事，所以我买了一本架构书来阅读模式和实践。

我尝试使用领域驱动设计对所有内容进行建模。我有一个代表我的世界的模型，一个将其存储在数据库中的存储库，以及一个与 UI 交互的服务层（即 WebForms，因为我在 MVC 方面的经验为 0，并且已经几乎无法完成这项工作）。

我很难掌握图层交互的正确方式。我的理解是模型应该是一切的基础。它不引用任何内容，其他层引用它。
问题一：对吗？

我越来越关心服务层。我注意到我正在开发一个非常贫血的模型，原因有两个：1，我的模型没有引用存储库，所以我不能通过模型​​存储任何东西。 2，我试图在事情发生时做事情（即，我将一个对象添加到对象列表中，因此我一次将其存储在数据库中，而不是在用户完成添加对象时一次全部存储）。所以很多工作都在服务层和代表层之间完成，模型就在那里并且看起来不错。

我开始担心——我处于开发的早期阶段，但我是被视为所有这一切的架构师的人。我不想要维护噩梦（我希望这个应用程序将使用多年）。与往常一样，时间是一个问题，我无法有效地准备/学习。任何帮助都会膨胀。 :-)

Answer 1

模型应该是一切的基础。它什么都不引用，其他层引用它。 问题一：对吗？

在域模型和持久性系统之间强制分离的典型方法是定义存储库。然而，持久性不是领域模型的一部分。

您的模型应该调用存储库

定义的方法

例如考虑这个完全假的存储库：

// Repository
public class SharepointRepository
{
   void SaveWidget(); // Implement
}

所以存储库只关心加载和保存数据，它们根本不包含您的任何域逻辑。

但是，如果您的模型与存储库紧密绑定，则会出现关注点分离问题。

所以在这种情况下，依赖注入就变得很有用了。对于前面的示例，您的模型必须显式实例化 SharePointRepository 并调用方法。一种更简洁的方法是在运行时注入存储库的依赖项，以便您的模型不关心。

namespace YourApp.Domain.Abstract
{
    public interface ISharePointRepository
    {
        void SaveWidget();
    }
}

基于此接口，您可以构建具体实现，并在运行时将依赖项注入具体实现。

namespace YourApp.Domain.Concrete
{
    public class SqlSharePointRepository : ISharePointRepository
    {
        void SaveWidget()
        {
          // Code that Saves the widget using the managed sql provider
        }

    }
}

所以在你的网络表单上：

当您收集数据时，您的模型将使用表单中的数据进行水合，并将调用存储库方法，但是存储库本身会在运行时注入到 asp.net 应用程序中，因此您可以将 SqlSharePointRepository 更改为RavenDbRepository 不会破坏您的应用程序。

要了解如何在 Webforms 中绑定您的存储库，请参阅此 SO 帖子：How can I implement Ninject or DI on asp.net Web Forms?

使用 MVC，控制器负责您认为自己正在经历的差距。但是对于您的问题，根据您当前的设计，模型应该调用存储库操作，但是存储库本身应该是松散耦合的。