Question

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

实施例

您有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);
    }
}

Answer 1

您所谈论的内容似乎是两种方法的混合。

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

然而，听起来你也想要一个从Domain Driven Design演变而来的设计，其中对象本身包含所有必需的逻辑（而不是带有＆＃34; Service＆＃34;类的六边形结构）。

DDD没有声明持久性是模型的一部分 - 但逻辑是。您仍然会将持久性保留在专用存储库中，但您的所有逻辑都将存在于模型中。然后您的存储库就会按原样更新模型。我们的想法是，您的代码在您的域的内部工作方式上变得更具表现力（这是您在代码示例中的目的）。

Answer 2

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

如果要覆盖方法怎么办？您现在正在扩展DTO而不是服务，从而产生新的DTO。在我看来，它太过于耦合了。

Answer 3

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

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

模型是否也可以作为存储库？

实施例

3 个答案: