关于实体的设计与疑问

做了几年的项目了，最早的时候用Hibernate,到后来直接用jdbc 或是 spring的jdbcTemplate。

可每每在设计实体的时候，实体与实体之间没有直接的关联关系，仅仅是与数据表字段一一对应，一直觉得有种不合理的感觉。

很多人很反对实体之间建关联关系， 一个class 仅仅是完成与数据库表的对应。  我觉得这种设计不太符合OO的思想。

但凡这样设计的，一般公司的流程是这样的：
1.分析需要求
2.建表
3.用工具类生成Pojo


如果是采用这样的开发流程，岂不是背离了OO的思想么？？

在MF的《企业架构模式》一书中提出来的事务脚本，就是这样做的，但是领域模型的概念，好像很少有公司采用

你可以在你的公司里面大胆地推行符合你的想法的设计呀，加油

百度搜 充血模型和贫血模型。

如果你的表是合理的，类也就合理了啊。

实体和关系型数据库表没有必然的联系。一个实体可以存储在不同的表中，一个表也可以存不同的实体，实体也可以不存储在关系型数据库中，数据库表也可以不存储实体。不要被惯常的偷懒的，面向数据库的设计风格所迷惑。

如果你打算采用领域模型驱动设计，那么你就要从业务领域出发，思考你的程序给什么人用，你的程序要怎么做才能给人提供业务价值，如何用你的程序反映业务领域，等等此类问题。至于领域模型如何被持久化，那其实是很灵活和自由的。在不伤害领域模型的情况下，怎么方便，怎么易于维护，怎么高效，就怎么来。

Hibernate的面向对象关系映射。好好利用。

我们已经放弃实体，全部用Map了。用ResultSetMetadata读出字段信息，做成Map，实体这层全部自动化。

不使用hibernate的关联映射的结果是，可以简单的采用对象导航访问数据的写法无法使用。

其实这是放弃了ORM的一个强大的功能，另外也严重影响hql的对象导航方式表达，

而且具我所知，外连接的hql在不配1对多的关联时是写不出来的。

库表有关系，而持久化类没有关系，软件本身就处在一种不一致的状态下。

只要有外键的地方，就应该有many-to-one 关联，只要记住谨慎使用one-to-many关联就行了。

没必要极端惧怕 事务脚本 和领域模型中的任一种，完全取决于你团队的习惯； 比方说，你的团队很熟悉hibernate，做到了实体和实体的关联，但是所有的实体都没有behavior————操作这些实体的方法都还在service里面，那也不是领域模型，但是也很好的保证了实体概念上的完整性。。说到底你的团队有能力做什么，就做什么

你觉得我这种概念我都不懂么？