新人求教关于面向对象设计的问题

[lemoningfido]

现在我做web mvc系统，用的orm获取对象，然后再通过service类做一些处理，转换为viewmodel返回给前台。
我有一事不明，就是我通过orm获取到的对象，属于贫血类型，只是数据，没有一些方法。
我在学习面向对象编程时，都会有关于一个对象好比是现实中的对象，属性和方法都有，方法就是某种行为。
但是这种方式我不知道如何应用到我的编程中去。
还希望有高手来解疑，谢谢。

[lr5420511]

你说的那个是DomainObject，比如一个人转账给另一个人，怎么设计这个领域对象呢？把动词和名词分析出来，动词就是转账，名词就是客户，任一个客户都有一个转账的动作完成后减少自己的余额，同时又有一个收款的动作完成后增加自己的余额，可能还会产生一条交易记录（相应表的数据增加）,而我们把这些动作协调组织在一起（可能还会判断余额是否足够），就完成了一个完整的转账过程。 我们有时候并不想把DomainObject的某些方法暴露出去，这时候可以专门设计DTO来进行数据的映射（你所指的贫血对象，无方法只有属性）。如何分析设计Domain层（包含数据和基元方法）和业务层（如何协调组织多个DomainObject工作和数据的持久化）是整个系统的关键

[猿敲月下码]

一个简单例子：贫血模型or领域模型

[落叶_yi片]

诶 (～￣▽￣)→))*￣▽￣*)ojava...

[IE11下面经常卡到爆]

不纠结概念，个人实际项目中偏领域模型，必要的时候也会增加DTO这种东西，比如组合的对象 分层还是蛮有必要的，层中各种对象的关系理理清楚，用例图画一画，该抽象（接口）的对象或者行为就提取出来

[娃都会打酱油了]

你所谓的这部分我个人理解应当是在service这块实现，但一般情况下，我们都是通过POCO（简单C#对象，也就是你说的贫血）来进行对象的属性传递，而该对象的相关业务则是对应的service来包含（这个service一般都是适用于特定POCO的），其实这种service写法只是原来的三层写法改了个名字而已，要实现你所谓的OO，那么业务对象应该与业务逻辑合二为一，也就是service层和domain层进行合并 再次补充，以上仅是个人理解，不对之处还请海涵

[各生欢喜]

感念是死的，多做几个项目，你就能理解感念