使用部分类-persistance无知-testability的实体框架DDD

Question

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

我叫，不感兴趣：

ignorance

• testing

• 持久性

我只关心一件事：

• keep应用程序organized
• keep things simple

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

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

Answer 1

因此，如果我对您的理解正确，您希望使用数据访问工具，特别是实体框架，来帮助实现您的应用程序。

听起来你实际上对这个项目的领域驱动设计不感兴趣。

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

不过，与其他人一样，我亦会提醒大家，不要沿着DDD路走一半路。领域模型的概念尤其如此。一旦您开始尝试实现一个真正的域模型，您实际上将需要DDD的其余部分，以使它为您工作。您会发现，如果没有DDD拼图的所有部分，您的应用程序将向贫血域反模式移动。

然而，如果你了解到你没有做DDD，只是提升了一些想法，你就可以为这个“贫血域模型”开车，这将是一件好事。

如果我没有因为这么说而被否决，我会感到惊讶的，但让我解释一下。

您可以使用ORM (EF)，使用存储库的概念(虽然我更愿意将其称为DAO --数据访问对象--以避免两者之间的混淆)，并使用标准的分层/洋葱体系结构实现应用程序。应用程序逻辑的大部分将使用直接反映数据库的数据类进入以事务脚本样式实现的服务。

这是一种经过时间测试的构建应用程序的方法。这不是DDD。这两种方法适合不同类型的更好，有不同的利弊等。

使用EF或类似的工具可以使应用程序的大部分实现变得简单和快速。只是不要陷入困境，试图做DDD，而你没有真正做DDD。

Answer 2

我认为你在使用一种技术，却不知道为什么它是好的还是坏的。根据我的经验，这几乎总是导致糟糕的应用程序设计。

任何说他们对测试不感兴趣的人，都是在梦游，后来在路上遇到了一大堆问题。

DDD的“简单”是以所有简单性、抽象层为代价的。阅读Evans领域驱动设计，然后您可能会意识到为什么它会导致更好的设计。

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