The Biggest Flaw of Spring Web Applications | Java开发人员在使用Spring应用是非常擅长谈论依赖注入的好处。不幸的是，他们不是那么真的利用它的好处，.

我是JAVA的的一个菜鸟，一直让我困惑的是为什么要把数据放到一个POJO类中，为啥不用一个map代替？ 数据交换用JSON，内部用Map, 系统是不是比用POJO简单多了？ .

1、首先使分类Category：public class Category { private String name;}简单期间先给个name，当然id每个model都有的，先省略掉了2、问题标签类.

在我们应用OO进行分析设计的时候,又提出了贫血和充血的概念.并产生了很大的争论.结合DDD，在这里,我也谈谈我的想法。 1.贫血模式说白了就是把对象看成是数据的载体.因为它不存在实际的操.

从“贫血”和“充血”说起这两个词对我来说也是很新鲜的，看看我在Jdon的注册日期也就是从那时候开始才有所耳闻的。这两天看到有人在讨论于是整理了一下思维。看到网络上很多的讨论中对于充血和贫血的看法往往是.

充血模型有什么实际的好处么？ 难道就为了好听 完美（数据和行为统一）？过于复杂的需求还是用贫血 ,一般需求用充血 ,这样做正确吗？项目中用的更多的哪个模型呢。比较困惑。。.

项目中的领域模型,我一直只为模型的各个属性提供set/get方法,这样的模型被称为失血模型,这样影响了对象的完整性,是一种不完全的面向对象设计,但在实际中,这样的设计我觉的很直观,而且可以加快开发速度.

如题.使用POJO产生了什么样的好处?怎么觉得从模型里把方法剥夺了，看起来那么奇怪呢?.

关于暴露业务模型（Exposed Domain Model Pattern） 这个问题涉及到企业应用社区中许多流行了好多年的热门词：POJO，DTO（VO），FAÇADE。这个问题非常复杂，比贫血模.

关于贫血模型 贫血模型的问题与所谓专家原则以及分层原则直接相关。面向对象系统的主要任务就是安排对象系统的责任划分以形成合理的协同关系；专家原则是说，某个功能、行为应该分配给持有相关信息最完整的对.

-->>失血模型　　MF（Martin Fowler）曾经提出有名的贫血模型或失血模型，让我们好生迷惑和彷徨，他认为实体模型对象中只有弱行为setter和getter方法，没有真正行为，好像缺少血液的.

对于公司简介，或者公司概况之类的只有一条记录，并且还要求能够修改的栏目，该如何设计和建模。我以前是把他设计成一个领域模型，但是不给他添加和删除的动作，但我老感觉这不够优雅。各位高手是这么做的呢？.

这如何理解?DDD我觉得很是能自圆其说的一种设计思想.一直想把的什么失血和贫血,BO,VO,POJO,还有怎么分层跟DDD作一个整合.一些基层框架可以DDD提供服务,比如ibatis,我觉得这.

大家能详细谈谈DTO、BO和PO吗？从它们三的本身和应用的环境。.

最近自己做了一个东西，也是看书看多了，就想自己实现一下，跟大家说说，给点意见我作的是一个很小的东西，类似于购物的网站，Domain层使用充血模型，对所有的Entity、ValueObject 进行建模.

今天在jdon看到一片关于领域模型的文章，心里总结了一下下面是个人观点！贫血模型是对OO的非常经典的诠释！数据交给s/g，业务全部交给业务对象来完成。耦合度很低，逻辑清晰，重构空间大！而且在业务逻辑上.

最近看domain model，好像大家都很摈弃失血模型，认为domain object中不能只有getter/setter代码，而应该加入不依赖於持久化的逻辑方法为什么呢？谢谢.

今天看了robbin在javaeye上关于domain object的总结:总结一下最近关于domain object以及相关的讨论我觉得jdon框架使用的是第一种贫血模型,而robbin说现在绝大多.

BO里的字段总会有各种类型：int、DateTime、string、float、decimal等。最近和个朋友正在架构公司的底层平台，朋友坚持所有的字段都用字符串来表示。小弟我总觉得这样做不妥.

web层向业务层，或业务层向web层传递数据时 常使用到的是DTO，如果使用Map怎么样？.

最近总是在思考Domain Logic Patterns的几种形式，这也让我不得不从先哲们的书中探寻答案。看了下martin 的Patterns of Enterprise Application A.

小弟现在做的项目，用的是mvc模式，现在在web这端，用command模式处理接受表单的数据，调用 业务逻辑端delegate的业务处理，现在遇到一个比较模糊的问题：在command端我传送的是jav.