关于为什么“贫血领域模型"被认为是反模式的具体例子 [英] Concrete examples on why the 'Anemic Domain Model' is considered an anti-pattern

问题描述

如果这是重复的，我深表歉意，但我在相关问题中找不到关于该主题的任何具体示例.

I apologize if this is a duplicate, but I couldn't find any concrete examples on the topic in related questions.

在阅读了 Martin Fowler 关于贫血域模型"的文章后，我不知道为什么会这样被认为是一种反模式.甚至大多数企业开发人员是否认为它是一种反模式，因为 AFAIK 可能 90% 的 j2ee 应用程序都是以贫血"的方式设计的?

After reading Martin Fowler's article on the 'Anemic Domain Model', I'm left wandering as to why is this considered an anti-pattern. Even does the majority of enterprise developers consider it an anti-pattern, since AFAIK probably 90% of the j2ee applications are designed in an 'anemic' way ?

有人可以推荐关于该主题的进一步阅读吗(除了领域驱动设计"一书)，或者更好的是，给出一个具体的例子来说明这种反模式如何以一种糟糕的方式影响应用程序设计.

Can someone recommend further reading on the topic (other than the 'Domain Driven Design' book), or even better, give a concrete examples on how this anti-pattern is affecting application design in a bad way.

谢谢，

推荐答案

给定以下两个类:

class CalculatorBean  
{  
    //getters and setters  
}  

class CalculatorBeanService  
{  
   Number calculate(Number first, Number second);  
    {  
       //do calculation  
    }  
} 

如果我理解正确的话，Fowler 是说因为你的 CalculatorBean 只是一堆 getter/setter 你不会从中获得任何真正的价值，如果你将该对象移植到另一个系统什么也不做.问题似乎是您的 CalculatorBeanService 包含 CalculatorBean 应该负责的所有内容.这不是最好的，因为现在 CalculatorBean 将其所有责任委托给 CalculatorBeanService

If I understand correctly, Fowler is stating that because your CalculatorBean is just a bunch of getters/setters you don't gain any real value from it and if you port that object to another system it will do nothing. The problem seems that your CalculatorBeanService contains everything that the CalculatorBean should be responsible for. Which is not the best as now the CalculatorBean delegates all of its responsibility to the CalculatorBeanService

这篇关于关于为什么“贫血领域模型"被认为是反模式的具体例子的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！