wlcome998

强烈建议使用数据库驱动（或者hbm驱动，但是hbm要根据数据库的设计来）

个人觉得这是最保险、最直观、最快速的做法

除非你的系统很小、不需要考虑性能问题

改造旧系统是不能或很难生成自己想要的结构的，对新系统用对象建模应该做对象缓存，应用服务器共享缓存达到性能优化。

这么多糊弄人的名词 用得着这么复杂么

感觉两者都需要兼顾，一个良好的设计必定你的闹钟都会既有领域模型，又有数据库模型，我们团队的方式一般都是兼顾，不过一般我们在数据库设计的时候也做了不少重构工作，兼顾领域模型和数据库模型，因为对于一些结构双方的映射方式还是有不少选择的。我觉得你们不管用哪种，肯定要先出一个设计，然后做映射，能端到端走通了的话，就可以进行开发

其实领域模型中的实体和实体关系模型中的实体能有多大区别呢？
领域中有些对象是要建模为每个都是不同的，那就建成实体咯。
然后实体和实体之间有关系，就有了实体关系模型中的关系
就有了领域模型中的关联关系。
对象中有继承关系，实体关系模型没有，但有很多策略可以进行映射[Fowler02]

然后对象建模-->实体关系模型

先设计实体，由实体生成表　吧。

是pro hibernate系列的书

请问是那本书？能给出书名吗?

个人感觉像是对前两种方法的一种优化或者折中

谢谢大家的讨论，最近偶然看到一本外文书，作者是参与Hibernate设计的开发人员，书中也对这设计的方式进行了讨论，作者就认为没有一成不变的设计方式，要根据具体的情况来做具体的设计方式，归纳为三种
1.POJO-Driven Approach
In the POJO-driven approach you start with an object/domain model, and using JSR-220 annotation or Javadoc metadata comments, you define how each field in a class maps to a database column. At runtime, Hibernate uses the annotations to dynamically create the mappings.
这种方法适用于数据模型还没创建和设计或者不明确的新应用程序
2.Data Model–Driven Approach
In the model-driven approach you start with a database schema for the chosen database system, and using a tool like Middlegen or Hibernate Synchronizer, you generate mappings and POJOs for each table being mapped. This approach provides a fast start-up time for development。
这种适合已建立明确的数据库或者数据模型的web开发，并能快速的开发。
但也指出使用这种设计的方式会造成域模型的semantic(语义)不够丰富，达不到你原先设想的那样。
3. 作者自己推荐的是一种是第三种方式，称为HBM-Driven Approach。
The two previous approaches, taking either a domain-model or data-model approach, typically result in HBM mappings that are not quite complete. Every time I use either of the approaches above in a moderately complex application, I find myself fine-tuning the HBM files to either
get more accurate POJOs (in the data-driven approach) or more efficient, manageable database
schema (in the POJO-driven approach). The third approach suggested here takes the stand that object-relational mapping is an inescapable, necessary evil that should be taken into consideration early and in a head-first fashion in the development of your application.By
creating detailed, accurate HBM files you will end up with both a domain model and a database schema that meets your application needs and ensures the longevity of the data

使用Hibernate时，应该先设计领域模型，从领域模型生成数据库表。

通过下列代码可以自动生成数据库表：

Configuration config = 
AnnotationConfiguration().configure("/hibernate.cfg.xml");

	SchemaExport schemaExport = new SchemaExport(config);
	// script, export, justDrop, justCreate
	schemaExport.execute(false, true, false, true);

然后再检查生成的数据库表，必要时进行优化（如添加索引等）。

基于数据库设计和基于领域模型设计，你真的没有必要把它分得那么清，楼主的意思可能是先有表呢还是先有对象，不管你是先建表还是后建表，数据表都是当你分析了业务逻辑后得来的，其实你已经不知不觉从领域模型开始了。 正如抛出异常的爱所言： 领域不是目的，目的是更好的抽象业务。

针对你的需求，我觉的你可以采用数据库设计方式。

通常决定是否基于数据库设计和基于领域模型设计取决于你的分析结果——分析模型。

众所周知：数据库设计基于两种设计粒度：表和字段；

如果分析模型和数据库存在如下差异，则应当考虑采用领域模型：
1. 表粒度所能提供的结构化能力无法支持分析模型，比如一个分析模型的数据是分布在多张表中，或者一张表中表示的分析模型有多种（即ORM所支持的几种继承能力，以及component）
2. 字段粒度所能提供逻辑无法支持分析模型，存在较多逻辑计算依赖多个字段甚至是不定字段。

如果以上两种情况都满足，那么采用领域模型设计，无疑拥有较好的设计开发成本，同时设计和分析的差异性在较小范围内，沟通成本也将保持较低的范围内

同学,表的设计不错!

不太理解异常兄的意思
下面一个基于B/S的学生在线评价教师的系统
evaluate_detalis表格是评价指标
1、evaluate_process表格是学生首先从界面里面选择所在班级的任课教师和相应的课程的每一个指标对其进行评价（选择评价等级 优良中差）
2、evaluate_result表格存放的信息是 当学生评价完毕时管理员对该老师的课程进行结束评价的操作，系统自动计算出每一个评价指标的加权评价等级并将结果写到这个表格里面

以下是这个系统可能的关系。。
针对这样的系统 如果使用Hibernate设计持久层 遵循怎样的设计流程最好呢

1.领域常用的是充血模型。
2.把一个表的内容尽量的减少。
3.由2之后把常用的统计查询用视图来表现
（如果业务充许的话还可以用影射视图缓存）

赐教了 异常兄不妨介绍下关于持久层方面的一些设计经验

两个不在同一个层次上。。。。
就如同别人说打地基时用的黄色的大理石。。。
可以让建筑物更高贵一样。。。（跟本没人看的见。。。。）

PS：OO不是目的，目的是把不好理解，容易出问题的部分封装。
领域不是目的，目的是更好的抽象业务。

我只是想知道使用Hibernate时，采用哪种模型驱动比较好