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

第二种方法的有一个致命的问题：

Item:public Bid placeBid(User bidder, MonetaryAmount bidAmount, 
                        Bid currentMaxBid, Bid currentMinBid); 

和

ItemManager:public Bid placeBid(Item item, User bidder, MonetaryAmount bidAmount, 
                            Bid currentMaxBid, Bid currentMinBid

的签名类似，耦合太强了，类似的方法会有类似的耦合性。
这么强的耦合性，最佳的办法就是合二为一。
我觉得第三种方法的变体好一些，但通过两个接口解决问题，一个IItem，一个IItemDAO，给外部的只是IItem，管他里面是不是依赖于DAO呢。

实践的结构第二种方案似乎只能在业务很简单的情况下使用，就我前面列举的很多业务规则的例子，基本上可使用第二种方案是个灾难。（如果我没理解错的话）

看看什么robbin对第二种模型的解释。带业务逻辑的实体类主要是为了更好的重用。但大部份的逻辑操作都通过业务逻辑层，即ItemManager，其中也对实体类的业务逻辑提供相应的封装方法。第一和第二种最大的差别在于实体类是否带有业务逻辑的所以我的做法是：
1、先按第一种模型进行开发。因为很多业务逻辑都只有一个专门对应的manager进行调用和管理，把业务逻辑放在manager层测试和管理修改调用都比较容易，也不用再对实体类进行业务逻辑的测试。
2、如果有两个或两个以上的XXXmanager都使用到某一实体类的同一业务逻辑的时候再进行重构，是采用第二种模型还是另建一辅助类我觉得都行。

第二种模型的最大的问题就是数据的来源，光看业务模型，似乎很漂亮，但是遇到真正复杂的逻辑，这些业务bean数据的取得便成了个灾难，而且，XXXManager的划分也很困难

以下是Martin Fowler的序

Foreword – Martin Fowler
ThoughtWorks started to work with J2EE in late 1998. At that time, we found a lot of cool (if somewhat immature) technology, but with little guidance on how to use it well. We coped, partly because we had a lot of experience in other OO server environments. But we've seen many clients who've struggled, not because of problems in the technology—but due to not knowing how to use it well.

For many years, I've been a big fan of patterns as a way to capture design expertise—to catalog practical solutions to recurring problems. Over the last couple of years, various pioneers have been working with J2EE and uncovering the patterns that make for an effective J2EE solution. This book is an excellent collection of those patterns, capturing many of the techniques that we had to discover by trial and error.

That's why this book is important. Knowing the APIs backwards is one thing; knowing how to design good software is something else. This book is the first book I've seen that's really concentrated on capturing this design knowledge, and I'm relieved to see they've done a damned fine job of doing it. If you're working with J2EE you need to be aware of these patterns.

Furthermore, this book recognizes that design doesn't end when you start writing code. People make decisions that don't turn out that way. In this situation, you need to fix your design and you need to fix it in a disciplined way. Refactoring is increasingly the approach of choice for making changes to an existing system. The authors are the first group to extend my work on refactoring into a new direction—into the world of J2EE design. Not just am I grateful that someone has built on my earlier work, I'm glad they've used their experience to outline how to do these transformations.

In the end, it's that experience that counts. Capturing design experience in books is one of the hardest things to do, yet is so necessary for our profession to grow. This book captures vital experience for J2EE development. Don't build an enterprise bean without it.

Martin Fowler
Chief Scientist
ThoughtWorks

frankensteinlin问：
“。。。上面的的需求和代码不一定正确但是意思就是想说明placeBid的时候还是需要很多对象的帮助才能完成任务，这些对象的的属性哪里来？ ”
这个问题很典型，也很实际，等待高手的解答。

我的一些看法：
1。placeBid所需其他对象的属性在manager中调用dao取得，然后作为参数传递给placeBid。（例子中的currentMaxBid，currentMinBid就是这种方式）
2。采用Active Record模式，在item类中直接进行Hibernate操作，（好像Ruby on Rail就是这样做的）
3。设计有问题。如果设计做得好，就不会出现frankensteinlin的问题。

我想是robbin一开始误导了大家,其实传统的Domain Object建模我想应该是这样,不存在任何双向依赖关系.

如一个工资单包括基本工资、奖金、个人所得税三个字段。而最后的实际所得应该=基本工资+奖金-税。这个总收入属性是数据库表中没有的，而是在实际业务中产生的，是业务逻辑的需要，那么这个属性应不应该包含在domain object中?

序列化是将对象转换为容易传输的格式的过程。例如，可以序列化一个对象，然后使用 HTTP 通过 Internet 在客户端和服务器之间传输该对象。在另一端，反序列化将从该流重新构造对象。

这里要明确一点：序列化不是序列化某个属性或方法，而是序列化对象（当然，对象中的属性和方法可以在定义时加上transient或static关键字以确保不被序列化）。

这里贴一个序列化的步骤，是。ＮＥＴ的，ＪＡＶＡ应该类似。我想我自己说的肯定没它说的好。
序列化过程的步骤
在格式化程序上调用 Serialize 方法时，对象序列化按照以下规则进行：

检查格式化程序是否有代理选取器。如果有，检查代理选取器是否处理指定类型的对象。如果选取器处理此对象类型，将在代理选取器上调用 ISerializable.GetObjectData。
如果没有代理选取器或有却不处理此类型，将检查是否使用 Serializable 属性对对象进行标记。如果未标记，将会引发 SerializationException。
如果对象已被正确标记，将检查对象是否实现了 ISerializable。如果已实现，将在对象上调用 GetObjectData。
如果对象未实现 Serializable，将使用默认的序列化策略，对所有未标记为 NonSerialized 的字段都进行序列化。

支持这个



不过如果逻辑简单的话，有几种方式是一样的，这个时候就无须认真区分了。

逻辑简单的话，第一个变种就会和第二个变种一样了

有的时候Item如果就是没有逻辑的话，也就谈不上是否贫血了。

Item中我一般只放一些简单的逻辑，例如把字符串处理一下，数字变换一下等等的新的方法