问题描述
现在我做webmvc系统，用的orm获取对象，然后再通过service类做一些处理，转换为viewmodel返回给前台。我有一事不明，就是我通过orm获取到的对象，属于贫血类型，只是数据，没有一些方法。我在学习面向对象编程时，都会有关于一个对象好比是现实中的对象，属性和方法都有，方法就是某种行为。但是这种方式我不知道如何应用到我的编程中去。还希望有高手来解疑，谢谢。
解决方案
解决方案二：
你说的那个是DomainObject，比如一个人转账给另一个人，怎么设计这个领域对象呢？把动词和名词分析出来，动词就是转账，名词就是客户，任一个客户都有一个转账的动作完成后减少自己的余额，同时又有一个收款的动作完成后增加自己的余额，可能还会产生一条交易记录（相应表的数据增加）,而我们把这些动作协调组织在一起（可能还会判断余额是否足够），就完成了一个完整的转账过程。我们有时候并不想把DomainObject的某些方法暴露出去，这时候可以专门设计DTO来进行数据的映射（你所指的贫血对象，无方法只有属性）。如何分析设计Domain层（包含数据和基元方法）和业务层（如何协调组织多个DomainObject工作和数据的持久化）是整个系统的关键
解决方案三：
该回复于2016-03-18 13:24:46被版主删除
解决方案四：
你所谓的这部分我个人理解应当是在service这块实现，但一般情况下，我们都是通过POCO（简单C#对象，也就是你说的贫血）来进行对象的属性传递，而该对象的相关业务则是对应的service来包含（这个service一般都是适用于特定POCO的），其实这种service写法只是原来的三层写法改了个名字而已，要实现你所谓的OO，那么业务对象应该与业务逻辑合二为一，也就是service层和domain层进行合并再次补充，以上仅是个人理解，不对之处还请海涵
解决方案五：
解决方案六：
诶(～￣▽￣)→))*￣▽￣*)ojava...
解决方案七：
不纠结概念，个人实际项目中偏领域模型，必要的时候也会增加DTO这种东西，比如组合的对象分层还是蛮有必要的，层中各种对象的关系理理清楚，用例图画一画，该抽象（接口）的对象或者行为就提取出来
解决方案八：
感念是死的，多做几个项目，你就能理解感念