总结一下最近关于domain object以及相关的讨论

这个总收入属性应该包含在domain object里面，但是domain object的这个总收入属性不必映射数据库。

这个讨论产生的Java序列化机制讨论分贴到这里：

http://forum.iteye.com/viewtopic.php?t=14707

关于序列化话题请在那里讨论

  看了Core J2EE  Patterns 觉得里面的话总结的很好
业务对象封装了内在的业务逻辑而应用服务封装了外在于业务对象的业务逻辑
loadItemById和findAll中的业务逻辑对于Item 来说不是内在的所以放在  Service中

谈论的比较激烈，看得也比较有味道，所以再来说一下我的理解
对于robbin的第二种也好，其他的也好我觉得都不是固定的，一个项目里可以有好几种模式，这取决于业务的不同

一般是这样的顺序：
Client-->Service-->D Object-->DAO-->DB
至于哪些该放在哪里，基本有这样的原则：（就是robbin的第二种了）
DO封装内在的业务逻辑
Service 封装外在于DO的业务逻辑

当然如果业务逻辑简单或者没有的话也可以：
Client-->D Object-->DAO-->DB

对于第二种的第一个变种固然是个好办法，但如Robbin所说也有缺陷如果有多个Servcie要调用DAO的话，就有问题了。合并也意味中不能很好的重用

说到底就是粒度的问题，分得细重用好，但类多、结构复杂、繁琐。分得粗（干脆用一个类干所有的事）重用差，但类少、结构简单。

呵呵所以你觉得最好，就是最好的

累啊，终于看完了，我还是大致同意robbin的分类以及划分自包含的domain logic和business logic的这个论调
总之这更多的是从技术层面上去考虑的，如果从项目实施来看，更重要的是得保证整个项目具有概念完整性，
不要产生东一个robbin设计，西一个parche设计

第二种模型的选择是无可厚非的，从概念上解释是不是可以这样说：

domain logic实际上就是应用数据逻辑，数据库提供的数据逻辑（比如字符函数）是一种通用的数据逻辑，而实际上任何一种应用（财务，税务等等）都是有其特有的数据逻辑，而这一层是数据库无法达到的，业务逻辑和数据逻辑的关系就是包含关系。使用上需要把握的就是，
如果此逻辑以为实际上的应用通用标准，可采用数据逻辑。
如果不是，应采用为业务逻辑，便于以后扩展

请教前辈们：
帖子开头提到的第二种模型里  带有业务逻辑的实体类，即Item   其中placeBid方法中有一句“this.getBids.add(newBid);  // 请注意这一句，透明的进行了持久化，但是不能在这里调用ItemDao，Item不能对ItemDao产生依赖！”，是真实的进行了持久化，保存到数据库中了，还是没有进行持久化，仅仅保存到session中了，以后必须在某个地方执行持久化？

如果确实进行了持久化（不管是先在session中临时保存将来一起提交，还是马上就提交了），持久化工作是由ORM工具Hibernate完成的，对吗？

如果不用ORM工具（如Hibernate），而是自己写代码实现，是不是 域模型层 就会与 数据访问层 产生双向依赖？

Robbin的意思应该是，placeBid方法可以放在Domain Object里的理由是因为可以不依赖于持久化的具体实现，而是设置"逻辑关系",具体的实现是由Hibernate透明完成. 所以必须依赖于具体实现的方法我们只有放到DAO里面去，因为否则会产生依赖.
绝对不应该出现Domain Object对DAO的依赖.

继续关注，如果一个DO里的的LOGIC跨越多个DO那么，凭什么这个LOGIC就属于这个DO？还是同意ROBBIN，只跟DO自己状态有关的LOGIC放到自己DOMAIN LOGIC里，贫不贫血是实际逻辑的问题，但是，一般情况下，实际逻辑只包含单一DO的操作很少，那实际逻辑就是贫血的，还管那么多干嘛？另外，我觉得还是反对在DO里以来DAO，双向关联很混乱

一口气看完了，凑凑热闹，发表一些看法：
对robbin的建议采用第2种模型，
可能在某些项目中确实很好（优点我就不重复了），但我认为它并不是适合所有项目。
原因有以下几点：
1，很多项目，需求相对不稳定，就是说开发过程中很可能对Domain Object进行或多或少的修改。当然Domain Object如果完全是手写的话，不存在任何问题，但如果是采用自动生成的方式的话，第2种模型就不是一个很好的选择。（实际上，我在项目中倾向于采用自动生成的方式，包括mapping等，所以基本上不考虑手动往里面添加任何方法）
2，根据robbin和大家的分析，第1种模型和第2种模型的最大区别也就是Domain Object里是否包含某些logic方法。
但是，
1）这里logic方法是有限制的，只有那些与DAO等非依存的logic才可以写在这里；
2）而在Manager/Service里还需要对Domain Object里的 logic方法进行简单的包装
由于1）的限制，可以写在Domain Object里的方法可以说大部分都是非常非常简单的。而本来简单的logic由有必要由2）Manager/Service进行简单的封装，我认为还是直接写在Manager/Service里好。

纯属个人看法。多多指教！