加布里埃尔,这被称为“

impedance matching problem”.有许多解决方案,从重量级的实体bean,如J2EE实体bean到Ruby ActiveRecord,再到简单的手工连接编码.

更新

好吧,很难在没有更多信息的情况下很难确切地知道如何攻击它,但这是基本的方法.

任何这些架构问题都是由性能等非功能性需求驱动的;此外,这里存在正确性问题,因为您希望确保以正确的顺序完成更新.因此,您需要考虑工作负载,即实际应用程序中的使用模式.考虑到这一点,您基本上会遇到一些问题：首先,应用程序中的基本数据类型可能无法正确映射到数据库(例如,代码中表示的VARCHAR属性是什么？),其次是域模型可能无法完全映射到您的数据库模型.

你想要的是让数据库和dmain模型解决,以便域对象的一个​​实例恰好是数据库模型中表的一行;在大型应用程序中,由于性能限制或预先存在的数据库模型所施加的约束,您很少这样做.

现在,如果您完全控制数据库模型,它会稍微简化一些事情,因为这样您就可以使数据库模型更接近域.这可能意味着数据库模型有些非规范化,但如果是这样,您可以(根据您的数据库)处理带有视图的数据,或者只是没有完全规范化的数据库.规范化是一种有用的理论构造,但这并不意味着你不能在真实系统中放松它.

如果您不完全控制数据库模型,则需要一层对象进行映射.在实现它时,你有很多选择可供选择：你可以在数据库中构建视图或非规范化表,你可以构建中间对象,或者你可以做两者中的一些,甚至可以有两个步骤(即,访问denormalizaed表的中间对象.)

但是,在这一点上,你遇到了“不要重复自己”和“做最简单的事情可能有效”的问题.想想最有可能改变的是什么？你的域名模型？如果你有一个强大的领域模型,那就不太可能了 – 业务变化相对较少.数据库中数据的确切表示？更常见的一点.或者,最常见的是确切的使用模式(比如发现需要处理并发更新).因此,当您考虑到这一点时,您需要做些什么才能使尽可能简单的方法来处理最常见的更改.

我意识到这并没有给你非常精确的指示,但我认为我们不能在不了解你的应用程序的情况下提供精确的指示.但是,当你已经在处理或多或少的工作时,我也会有一种印象,你想知道处理这个问题的“正确”方式是什么.所以,我最后会问“你现在对什么不满意？”和“你想怎么解决这个问题？”