dd_macle
2008-03-07 01:15
首先非常感谢goddie兄的回复,通过hbm.xml自动生成数据库表的方式在系统没有上线运行的情况下是可行的,但对于一个已上线运行的系统,数据的迁移怎么解决呢?

ghostv1
2008-03-13 11:15
数据库和业务模型是两个不同的结构,不需要一一对应,所以你只要写一层Adaptor适配数据库和业务对象。

这也就是是说一个业务对象可能是一个表,也可能是多个表的组合,但是从业务上来讲,我们不需要关系数据库

saharabear
2008-04-01 10:09
我现在也比较关心数据迁移的工作.在针对业务的变化可以将数据层的变化交给Mapping工具去做,而需要兼容现有系统的时候,问题就会比较多.我个人感觉还是需要DBA保证数据的安全.

但对于程序人员可以不考虑这部分.

有没有其他更好的思路?

OnRoad
2008-05-15 22:21
对于领域建模中的仓储始终看不太明白,哪位看懂的能不能解释一下?万分感谢!

usejava
2009-05-14 14:50
我也有和lz一样的问题,困惑很久,也在其他帖子里提到过,但是都没人回答。

banq
2009-05-14 15:48
>是不是会造成领域层与数据层之间的不一致,这个不一致对于软件的维护会不会带来影响?

这个就由一些ORM框架完成,比如Hibernate等,如果是JDBC就只好自己手工完成,这就是对象和数据库不匹配的烦恼。

ACoder
2009-05-14 21:20
除非一开始你能想到所有的因素,否则持久化层一定会变化。至于变化的多寡确实很难判定。

usejava
2009-05-15 08:46
是否可以设计建模用DDD,具体实现的时候,我指的是持久化这部分,不用Hibernate等ORM框架,而是采用一种可以自己控制数据库结构和SQL语句的方法(比如iBatis,也许不行,没仔细研究)。这样既可以发挥DDD分析描述问题的长处,也可以发挥传统数据库技术的优势。同时尽量保持数据库稳定。

ACoder
2009-05-15 20:49
如果需求是变得,那么模型必然也是变的。模型是变的怎么能够要求持久化成的东西不变那??

不过我比较喜欢自己实现持久化的过程,这样更加可控。

beepbug
2009-05-16 11:14
需求变化?需求变化可以粗略分两大类:与数据结构有关的及与数据结构无关的。如果是前者,没办法,只好“雄关漫道真如铁,而今迈步从头越”。因此,老手们经常有这样的感叹:数据一定得规划好啊,不然会倒大霉的。

BinnyJ
2009-05-16 18:34
模型改变,针对实体对象有变动,那些对应的数据库结构必然修改,

个人感觉没有什么疑惑啊。。

usejava
2009-05-16 23:11
问题是已经正式运行的系统很难接受数据库结构改变。

我比较赞同ACoder的观点:

>>不过我比较喜欢自己实现持久化的过程,这样更加可控。

正在寻求如何结合DDD

猜你喜欢
2Go