富域模型和ORM

问题描述

Martin Fowler认为贫血领域模型是一种反模式.

Martin Fowler considers Anemic Domain Model as an anti-pattern.

由于对象关系阻抗失配，将持久性模型转变为域模型似乎也很困难.一个>.出于持久性和规范化的考虑，我们倾向于将类分解为非常小的片段，在这些类之上的拍打方法很愚蠢.再加上持久性很少改变，但是业务逻辑改变了很多.

Rolling the Persistence Model as the Domain Model seems severely off too due to Object Relational Impedence Missmatch. For persistence and normalization sakes, we tend to break down classes to very small tiny pieces, slapping methods on top of these classes is silly. Plus persistence rarely changes, but business logic changes a fair bit.

因此，我们需要一个基于持久性模型(而不是一个或多个)的DomainModel.然后，该域模型将包含业务逻辑属性和方法.

So we need a DomainModel that builds on the persistence model (instead of being one and the same). This Domain Model will then contains business logic properties and method.

但是现在这些域模型仍在服务中，为了将它们公开给外界，我们需要将它们转换为DTO.

But now these Domain Models are still behind the service, and in order to expose them out to the outside world we need to convert them over to DTOs.

我们在这里做很多映射.

We are doing so manny mappings here.

1. 对域模型的持久性
2. 将域模型转换为DTO以在服务之间传递

它并没有就此结束，因为DTO可能需要映射到ViewModel中.

It doesn't end there, since the DTO may need to be mapped into the ViewModel.

所有这些以及重复验证逻辑的问题仍然没有解决，因为客户端需要实时验证. ViewModel对验证一无所知，因此例如在SPA中，您不得不在客户端(通常在javascript中)再次重写验证逻辑.

All that and the problem of duplicating validation logic still doesn't go away, because the client wants real time validation. ViewModel knows nothing about validation, so in an SPA for example, you're forced to rewrite the validation logic again, on the client side (usually in javascript).

本质上，服务也是无状态的(面向消息或RPC)，因此我们在持久性到OO再到过程到过程之间进行所有这些映射，这有什么好处?从大多数IT预算的实际角度来看，您如何证明成本合理?

Also services are by nature stateless (message or RPC oriented), so we're doing all these mapping, between Persistence, to OO then back to Procedural, to what benefit? How would you justify the cost in practical terms of most IT budget?

我知道具有完整的DDD，聚合根，域模型等将是多么酷"，但是您如何证明成本和对开发人员生产力的影响呢?

I get how having full DDD, with Aggregate Roots, Domain Models etc. would be "cool" but how can you justify the cost and the hit on dev productivity?

如果是这样的话，DDD和Rich Domain Model不会比精益"领域模型适合上面的反模式定义.抱歉，我鄙视加载的单词"Anemic".

And if so, wouldn't DDD and Rich Domain Model fit into the anti-pattern definition above than the "Lean" Domain Model. Sorry, I despise the loaded word, "Anemic".

通过保留域模型，精益"实际上允许您共享它，而不会违反抽象依赖原则"，不要重复自己"以及映射一个数据载体的耗时，乏味且容易出错的过程到另一个，以及与之相关的任何单元测试(除非您正在考虑不进行单元测试的映射，并希望获得最好的结果).

By keeping the Domain Model, "Lean" you actually allow it to be shared without violating the "Abstract Dependency Principle", "Don't Repeat Yourself" and the time consuming, tedious and error prone process of mapping one data carrier to another, and whatever associated Unit Test that goes on top of that (unless you're thinking of doing mapping w/o unit testing and hope for the best).

推荐答案

似乎您在混淆很多概念，将富域模型方法归咎于它不直接负责的事情.

It seems you're mixing up a lot of concepts, blaming the rich domain model approach for things it isn't directly responsible for.

• 丰富的领域模型与分层体系结构正交，尤其是拥有丰富的领域模型并不能决定您拥有的层数，在这些层之间应该交换什么数据结构以及如何映射它们.

• Rich domain model is orthogonal to layered architecture, especially having a rich domain model doesn't dictate the number of layers you have, what data structures should be exchanged between these layers and how they should be mapped.

丰富的域模型与验证正交，除了后端验证外，没有提到客户端检查的必要性.

Rich domain model is orthogonal to validation and says nothing about the need for client-side checking in addition to back-end validation.

换句话说，使您的域模型与服务中的所有业务逻辑贫乏，并不一定会使您不必编写大量的样板DTO映射代码，也不会消除客户端双重检查"的需要(顺便说一下，这是一种公认​​的最佳做法.

In other words, making your domain model anemic with all business logic in services won't necessarily save you from writing a lot of boilerplate DTO mapping code, nor will it remove the need for client-side "double checking" (which is by the way a commonly accepted best practice).

这并不意味着您对成熟的多层体系结构的成本和重量的观点是无效的.您可能会对Mark Seemann讨论类似问题的这篇文章感兴趣: http://blog .ploeh.dk/2012/02/09/IsLayeringWorthTheMapping.aspx

This doesn't mean your point about the cost and weight of a full-fledged multi-layered architecture isn't valid. You might find interest in this post by Mark Seemann discussing similar concerns : http://blog.ploeh.dk/2012/02/09/IsLayeringWorthTheMapping.aspx

这篇关于富域模型和ORM的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！