asp.net-mvc - NHibernate可以使用纯DDD方法吗？

Question

我一直在阅读DDD的内容，但对于使用像NHibernate这样的ORM时，如何使用它会感到困惑。

现在，我有一个带有相当“胖” Controller 的.NET MVC应用程序，并且我试图找出最好的解决方法。将这种业务逻辑移至模型层将是实现此目的的最佳方法，但是我不确定如何做到这一点。

设置我的应用程序是为了使NHibernate的 session 由HttpModule管理(使 session /事务不受干扰)，供返回实体对象的存储库使用(想想S＃arp arch ...结果是一个真正重复的a他们的许多功能)。这些存储库由DataServices使用，它们现在只是存储库周围的包装器(它们之间的一对一映射，例如UserDataService需要一个UserRepository或实际上是一个存储库)。这些DataServices现在仅确保在保存/更新时检查装饰实体类的数据注释。

这样，我的实体实际上只是数据对象，但不包含任何实际逻辑。虽然我可以在实体类中添加一些内容(例如“批准”方法)，但是当该操作需要执行诸如发送电子邮件，触摸其他不相关的对象或例如检查是否如果有任何用户在批准之前具有相同的电子邮件，等等，那么该实体将需要访问其他存储库，等等。将这些IoC注入(inject)到NHibernate中是行不通的，因此您必须使用工厂我假设要得到这些模式。我看不出您如何在测试中 mock 那些。

因此，我认为，下一个最合乎逻辑的方法是实质上每个 Controller 都有一个服务，并将当前在 Controller 中完成的所有工作提取到每个服务的方法中。我认为这与DDD想法相违背，因为逻辑现在不再包含在实际的模型对象中。

我猜想的另一种看待方式是，这些服务中的每一个都与它所针对的数据对象一起形成了一个单一模型(数据存储字段的分离和对其进行操作的逻辑)，但是我只是想看看其他的正在使用像NHibernate这样的ORM(通过返回填充的数据对象和存储库模型来工作)来解决DDD的“胖 Controller ”问题。

更新了
我想我的问题是我如何看待这个问题:NHibernate似乎将业务对象(实体)放在堆栈的底部，然后对存储库进行操作。这些存储库由服务使用，这些服务可以使用多个存储库和其他服务(电子邮件，文件访问)来执行操作。即:“应用程序”>“服务”>“存储库”>“业务对象”

我正在阅读的纯DDD方法似乎反射(reflect)了Active Record的偏见，其中CRUD函数存在于业务对象中(我将其直接称为User.Delete而不是Repository.Delete从服务中删除)，而实际的业务对象句柄这种情况下需要完成的事情的逻辑(例如，向用户发送电子邮件，以及删除属于该用户的文件等)。 IE。应用程序>(服务)>业务对象>存储库

使用NHibernate，考虑到NHibernate的运行方式，使用第一种方法似乎会更好，并且我正在寻找逻辑上的确认。或者，如果我只是感到困惑，请澄清一下这种分层方法应该如何工作。我的理解是，如果我有一个“批准”方法来更新User模型，并将其保留下来，并说给几个人发送电子邮件，则该方法应继续使用User实体对象，但要考虑适当的IoC，这样我注入(inject)messagingService，我需要在服务层而不是在User对象上执行此操作。

从“多个UI”的角度来看，这是有道理的，因为做事的逻辑是从我的UI层(MVC)中提取出来的，并放到了这些服务中的...但是我实质上只是将逻辑分解为另一个类，而不是直接在 Controller 中进行操作，并且如果我不再涉及任何其他UI，那么我只是将“胖 Controller ”换成了“胖服务”，因为该服务实际上是要封装的每个 Controller Action 执行工作的方法。

Answer 1

DDD 而不是是否具有Active Record倾斜。删除是而不是一种应在DDD中的实体(如用户)上使用的方法。

NHibernate确实很好地支持DDD方法，因为它与实体类的分离程度仍然很高。

when that action needs to do something like sending an e-mail, or touching other non-related objects

似乎您缺少的难题之一就是域事件。域实体不应直接发送电子邮件。它应该在域中引发一个事件，表明发生了一些重大事件。实现一个类，其目的是在事件发生时发送电子邮件，并注册该类以监听域事件。

or, for instance, checking to see if there are any users that have the same e-mail before approving

在提交调用“批准”之前，应该检查一下这一点，而不是在进行批准的功能中进行检查。将决定推高到调用代码中。

So the next most logical way to do it, I would think, would be to essentially have a service per controller

如果这样做是在理解服务是客户端的入口点的情况下完成的，那么它就可以工作。该服务的目的是从前端/客户端接收DTO中的参数，并将其转换为针对实体的方法调用，以执行所需的功能。