实体方面的设计，是从实体类还是从表开始？

项目设计中，一般都是从需求中抽象出usercase，然后再抽象出各种类。

关于实体类的设计，我有些想法。
因为项目中需要用到Hibernate，所以实体类是少不了的。（即使不用Hibernate，也应该少不了，呵呵）。如果直接设计实体类，像各种关系如（many-to-many），直接用类图好像比较难表达。而且担心这样的类能否自动生成最后的表。

如果从表开始，关系就比较好处理，然后利用Hibernate的工具，从表生成实体类。

不知各位有何想法？

经过项目实践,  总结出先设计表的几个缺点:

1.  各种不同数据库间类型与 Java 类型映射关系不同导致 E-R 设计的难度,  使得 o/r 的数据库可移植性大打折扣。

2.   business 发生变化 需要修改 表结构时,  需要修改的地方有 表, 映射文件, 实体, E-R 图,  这些工作都非常繁琐且容易出错,  如果先设计 Entity Object,  不会存在上述问题.

3.  非 OO 的设计思路可能会导致涉及到多表查询的复杂度增加.

这个可以理解。



先设计类，如果business变化，至少类，映射文件，E-R图也要改的。也有可能修改表结构的吧。

business 变化 -> 修改 EntityObject, XDoclet 重新生成 .hbm,  ddlupdate 更新表,  逆向工程生成 E-R 图,  修改只发生在 EntityObject

我觉得各有个的好处，主要还是根据你的系统具体情况来。领域对象驱动有他的好处，如楼上所说。关系驱动也有他的特点，如果是一些legacy系统,甚至不可避免。个人感觉关系模型形成的entity，也可直接做为domain object用，只不过颗粒度相对细一点，业务逻辑的变化，对我的service layer或者biz object影响相对大些，然而给entity object甚至整个持久层并没有带来多大的麻烦