|
锁定老帖子 主题：如此orm?
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-11-12
前期数据库没设计合理，麻烦是必然的。
|
| 返回顶楼 | |
|
发表时间：2008-11-12
无耻的引用某大牛的话，好的设计不是预计出来的，而是重构出来的，这也先天性的契合迭代重构和敏捷的开发理念，永远不要over design，永远不要拒绝变更，拥抱变更虽然一开始觉得痛苦，但变着变着就习惯了
|
| 返回顶楼 | |
|
发表时间：2008-11-13
这么多同学留言，我来进行整理下。
其实所有的留言可以归结为两种意见。而且，主要都是集中在hibernate的使用上面。 1。在开发过程中，如果表结构经常被改变，那么po也随着被改变是正常的。不正常的是：表结构被经常改变。理由是： garyzhangmin 写道 按理来说数据结构定好就不应该再修改了，前期花大量时间考虑数据结构分析业务需求是很重要的，考虑周全的数据结构是不再需要修修改改的，所以楼主这种经常改动表结构的问题不应该发生 2。在开发过程中，表结构被改变，po也得随着改变。表结构是经常被改变的。理由是： Joo 写道 无耻的引用某大牛的话，好的设计不是预计出来的，而是重构出来的，这也先天性的契合迭代重构和敏捷的开发理念，永远不要over design，永远不要拒绝变更，拥抱变更虽然一开始觉得痛苦，但变着变着就习惯了 其实说实话，2种意见都没有问题。不过我更倾向于第2种。我不是神，我想任何一个人都不是神。没有人会一次性的就把所有的东西考虑到。重构必不可少。表结构修改也是不可避免的。 那么，看来如果真有一个类似于我说的orm，应该还是值得一试的。 |
| 返回顶楼 | |
|
发表时间：2008-11-13
所有的VO(Entity)都不要了, 全用Map可以么? 还真有不少系统是这样设计的.
够灵活,快赶上动态语言了. 优点是, 省时间, 易修改. 不过, 缺点也不少.比方, 无法做编译期间的错误检查, 无法直观的了解对象关系, 少了一层Mapping关系使得DB与Entity完全耦合. 小应用可以这样做, 大应用就会带来很大成本提升.最主要的是, 交流成本在小应用中, 很小很小, 在大应用中, 交流成本是非常高的. |
| 返回顶楼 | |
|
发表时间：2008-11-13
最后修改：2008-11-13
starfeng 写道 所有的VO(Entity)都不要了, 全用Map可以么? 还真有不少系统是这样设计的.
够灵活,快赶上动态语言了. 全部用map，如何知道对象中的关系呢？还是把Map封装以下的好！ starfeng 写道 优点是, 省时间, 易修改. 确实如此！ starfeng 写道 无法做编译期间的错误检查。
这个无法避免，一开始也就提到了。等待jvm层实现真正的范型。而不是现在的阉割版本。 starfeng 写道 无法直观的了解对象关系。
所以，需要封装Map成Entity。 starfeng 写道 少了一层Mapping关系使得DB与Entity完全耦合。
1。hib中或符合jpa规范的orm中所谓mapping关系，其实是通过xml或者annotation来实现的。这样子的实现对于旧系统来说，很好很强大。因为极有可能table以及column命名不规范。这样通过配置文件，就可以达到平衡。 2。采用这种Entity方式的实现，必须保证db的命名规范性。否则，程序难以读懂。所以，采用此种方式，文档必不可少。 starfeng 写道 小应用可以这样做, 大应用就会带来很大成本提升.最主要的是, 交流成本在小应用中, 很小很小, 在大应用中, 交流成本是非常高的.
1。所谓交流成本，在客户和公司之间似乎，不会到这个层次。 2。在开发人员与开发人员当中，则可能要付出一点成本。但是，如果文档全面而且准确，应该是没有问题的。 |
| 返回顶楼 | |
|
发表时间：2008-11-14
jacklondon 写道 RyanPoy 写道 魔力猫咪 写道 问题是其实应该用对象生成数据库。Hibernate本来就不是为面向数据库准备的。它的适用范围是从对象构建程序。
hibernate是以对象为中心，不过事实是在开发中，有多少人是以对象为中心进行开发的。我想大部分还是以数据为中心吧。 ------------- 郁闷一下。为什么没有人回帖呢？难道大家目前的开发效率都足够快，这个东西根本就没有必要？ Hibernate 作者写 Hibernate 的本意，是觉得 SQL 难写、手工写 SQL 效率低。因此它本意也是面向 SQL 数据库的。Hibernate 文档中很少提到对象数据库，Hibernate 作者写书也很少提到对象数据库。 我不明白，为什么那么多人讨厌 SQL 数据库，而喜欢很少有人用的对象数据库？ 我可没说Hibernate用的是对象数据库。对象数据库根本就不需要Hibernate这种东西。 没人讨厌传统的关系数据库。短时期内对象数据库还不可能撼动关系数据库。 其实如果你对象设计得很合理的话，你会发现，Hibernate生成的表也和标准的符合第三范式的表结构很相像。 对象设计之所以取代了数据库设计，主要是因为数据库设计只能表示二维关系，对很多复杂的业务关系表示起来比较复杂，不容易理解。 |
| 返回顶楼 | |
|
发表时间：2008-11-14
用hibernate然后以数据库为中心，那是一种痛苦。楼主抛弃掉以数据库为中心的想法，一切就都ok了。
|
| 返回顶楼 | |
|
发表时间：2008-11-14
Hibernate不仅仅的一种新的技术,它还带来了一种新的设计思想,以实体为中心,而不是以数据库表为中心,这种思想将在ejb3中延续
|
| 返回顶楼 | |
|
发表时间：2008-11-15
囧rz。如果用hibernate插件，每次修改只需要改一下hbm.xml然后重新生成一下entity就行了啊。貌似不会很复杂吧。个人觉得非常简单。1分钟就OK了。原有CRUD代码不需要改动。
倒是如果用jdbc或者ibatis，那才是真正的苦恼。如果某个表增加了字段，要改所有CRUD的语句。囧到极点。 |
| 返回顶楼 | |
|
发表时间：2008-11-15
RyanPoy 写道
public class Entity
{
protected TableMapping tlbMapping; // 与数据表的结构映射关系
protected Map<String, Object> attrs; // entity的属性
protected Set<Class<?>> hasOne; // 1对1
protected Set<Class<?>> hasMany; // 1对多
protected Set<Class<?>> belongsTo; // 多对1
protected Set<Class<?>> hasAndBelongsToMany; // 多对多
public class User extends Entity
{
}
对于这里的protected Set<Class<?>>这里的关联关系是怎么用泛型来体现的,可以解释下么? 还有个问题是 tlbMapping主要存放的是些什么内容啊?是不是数据库表中,有哪些字段,字段的长度,是否主键这些信息么? |
| 返回顶楼 | |
