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

Question

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

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

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

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

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

Answer 1

模型应该是一切的基础。它不引用任何内容，其他层引用它。
问题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
        }

    }
}

因此，在您的 Web 表单上：

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

要了解如何在 Webforms 中绑定存储库，请参阅此 SO 帖子：我如何在 asp.net Web 表单上实现 Ninject 或 DI？

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