模型也应该用作存储库吗？答案

【问题标题】：Should model also serve as a repository?模型也应该用作存储库吗？
【发布时间】：2014-06-18 23:28:34
【问题描述】：

我想知道将模型用作存储库是否正确。原因是它会更简单，并且在某些情况下会更有意义。我不确定这是否是最好的做事方式，所以也许有人可以指出我的方向是否正确。

示例

你有Account，每个Account 都会有Sessions 和Projects。现在做acc.AddProject("new project") 和acc.DeleteProjectById(3) 之类的事情而不是在控制器中拉取存储库并浪费代码空间不是更明智吗？

这是我到目前为止所拥有的，我想知道我是否会朝着正确的方向前进。

public class Account
{
    public ObjectId Id { get; set; }
    public string Email { get; set; }
    public string PasswordHash { get; set; }
    public string PasswordSalt { get; set; }

    public IQueryable<Project> Projects
    {
        get
        {
            var kernel = NinjectWebCommon.Bootstrapper.Kernel;
            var projectRepository = kernel.Get<IProjectRepository>();

            return projectRepository.GetByAccountId(Id);
        }
    }

    public IQueryable<AccountSession> Sessions
    {
        get
        {
            var kernel = NinjectWebCommon.Bootstrapper.Kernel;
            var sessionRepository = kernel.Get<IAccountSessionRepository>();

            return sessionRepository.GetByAccountId(Id);
        }
    }

    public Project AddProject(string name, string description)
    {
        var kernel = NinjectWebCommon.Bootstrapper.Kernel;
        var projectRepository = kernel.Get<IProjectRepository>();

        return projectRepository.Add(name, description, Id.ToString());
    }

    public AccountSession AddSession(string ip, string hash, string salt)
    {
        var kernel = NinjectWebCommon.Bootstrapper.Kernel;
        var sessionRepository = kernel.Get<AccountSessionRepository>();

        return sessionRepository.Add(Id.ToString(), ip, hash, salt);
    }
}

【问题讨论】：

标签： c# model-view-controller coding-style standards

【解决方案1】：

您所说的似乎是两种方法的混合。

首先，在模型上使用这些方法类似于Active Record Pattern。这种模式基本上意味着每个对象都有CRUD 操作。

不过，听起来您还想要一个从 Domain Driven Design 演变而来的设计，其中对象本身包含所有所需的逻辑（而不是带有“服务”类的六边形结构）。

DDD 没有声明持久性是模型的一部分——但逻辑是。您仍然会将持久性保留在专用存储库中，但您的所有逻辑都将位于您的模型中。然后您的存储库将按原样更新模型。那里的想法是，您的代码对于您的域的内部运作变得更具表现力（这就是您的代码示例所要实现的）。

【讨论】：

【解决方案2】：

我通常不会。我喜欢将我的服务与它们传递的 DTO 分开。减少耦合主要是个人喜好。

如果你想重写方法怎么办？您现在正在扩展 DTO 而不是服务，从而产生新的 DTO。在我看来，耦合太多了。

【讨论】：

【解决方案3】：

我不会那样做。这听起来不像DDD。让我指出几件事为什么不是。

模型应该与应用程序中的其他层松散耦合，这意味着不依赖于域层两侧的层（即数据库和外观层）。
域模型应侧重于特定的业务操作域。并不意味着它必须自己进行操作。
模型应与应用架构中的其他层隔离。
假设我需要实例化模型对象以序列化为 json/xml，并且序列化过程正在由其他存储库对象完成，那么实例化该域的模型+存储库是没有意义的。
它应该是一个抽象且清晰分离的层，便于维护、测试和版本控制。

【讨论】：