实体框架 DDD 使用部分类-持久性无知-可测试性答案

【问题标题】：Entity Framework DDD using partial class -persistance ignorance -testability实体框架 DDD 使用部分类-持久性无知-可测试性
【发布时间】：2011-05-10 17:08:36
【问题描述】：

我想在我的应用程序中使用实体框架和自动生成的类。

我不对以下内容感兴趣：

坚持无知
测试

我只关心一件事：

让应用程序井井有条
保持简单

我阅读了有关域驱动设计的文章，我对此很感兴趣，因为它声称可以简化复杂的应用程序。但是当我从真实的应用程序示例中阅读代码时，我对这种方法的复杂性感到震惊。

我的想法是使用部分类来扩展从 EF 生成的类。有人尝试过这种方法，可以给我一些建议吗？

【问题讨论】：

那么让我直截了当——您对 DDD 感兴趣，但对持久性无知和测试不感兴趣？你是真的吗？？听起来您想要 DDD，但不希望努力参与其中。不要做半成品——第一次就做对。这是我的看法。
我不能只看到黑色或白色。我不在我的老板头上。我的老板叫我创建这个应用程序，不要关心测试。
告诉你的“老板”，因为这个决定，你将花费大约很多更多的时间来维护应用程序。我知道，因为我过去为此付出了代价，并吸取了教训。

标签： c# asp.net-mvc entity-framework architecture domain-driven-design

【解决方案1】：

我认为您在使用一项技术时并不了解它为什么好或坏。以我的经验，这几乎总是会导致糟糕的应用程序设计。

任何说他们对测试不感兴趣的人都是在以后梦游成山的问题。

DDD 的“简单性”是以所有简单性和抽象层为代价的。阅读 Eric Evans 领域驱动设计，然后你就会明白为什么它会带来更好的设计。

我个人认为你会输在这个等式中。你是一个职业，你应该考虑“不考虑测试”这句话的含义。如果您将其提供给客户，如果应用程序中断，会发生什么情况？老板会怪谁？他们自己？非常非常小心。

【讨论】：

我再说一遍：我现在对测试不感兴趣。将来我会读埃文斯的书。目前我只对 ddd 的一个方面感兴趣。
“保持应用程序井井有条”不是 DDD 的一个方面。您需要更具体 - 您想最小化文件吗？还是说架构？

【解决方案2】：

所以，如果我的理解正确，您希望使用数据访问工具，尤其是实体框架，来帮助实现您的应用程序。

听起来您实际上不有兴趣为这个项目做领域驱动设计。

我认为这是一个很好的位置。DDD 结合了在 DDD 之外有用的想法、模式和工具。

但是，像其他人一样，我会谨慎地在 DDD 道路上走一半。对于域模型的概念尤其如此。一旦你开始尝试实现一个真正的领域模型，你实际上将需要 DDD 的其余部分才能让它为你工作。您会发现，如果没有 DDD 难题的所有部分，您的应用程序将转向贫血域反模式。

但是，如果您知道自己不是在做 DDD，只是从中汲取一些想法，那么您就可以为“贫血的领域模型”而努力，这将是一件好事。

如果我这样说没有被否决，我会感到惊讶，但让我解释一下。

您可以采用 ORM (EF)，采用存储库的概念（尽管我更喜欢将其称为 DAO - 数据访问对象 - 以避免两者之间的混淆），并使用标准的分层/洋葱实现您的应用程序建筑学。您的大部分应用程序逻辑将进入使用直接反映您的数据库的数据类以事务脚本样式实现的服务。

这是一种经过时间考验的构建应用程序的方法。它不是 DDD。这两种方法更适合不同类型的人，有不同的优缺点等等。

使用 EF 或类似工具应该可以简单快速地实现大部分应用程序。当你没有真正在做 DDD 时，不要因为尝试做 DDD 而陷入困境。

【讨论】：