|
从面向对象的角度考虑问题，意味着你可以使用封装，集成，多态这些面向对象的特点来描述和理解你的应用域，因为对象的高度抽象和可理解性，通过它你可以构造出一个用对象来描述领域的模型，这也是领域模型的由来。而一个好的模型必然要考虑到的几点包括对象所包含的责任是否合理，对象与对象之间的关系是否合理等，而高内聚，低耦合就是用来衡量它们的一个技术标准。 所以当你不是用对象的方法(不是说你仅仅使用了面向对象语言)来分析解决问题时请离O/R M远一点，这样对大家都好。你不会觉得它奇怪，它也不会被你用的郁闷。 在这里我也顺便谈谈我对DLinq的看法。首先我不得不承认它很Cool,并且我之前对Linq也做过介绍，但是我并不是很喜欢它的方式，至少它存在一种可能被滥用的危险。查询你所需要的数据，然后围绕这些数据做处理，微软仍然坚持它一惯的风格，并且在Linq中，可以说是做到了极致---用Linq查询数据太方便了。如果每个对象都通过这样的方式获得，那么对象之间的关系(Association)将变的杂乱无章。你在设计对象的时候仔细考虑的对象之间的关联关系将被轻易的打乱(领域对象的关联关系是描述领域模型的关键组成部分之一)，而且你查询到的纯粹是数据实体，它们并没有行为，你又会靠一个个的xxxManager来管理它们，喔，天哪，又失去了面向对象的优势。所以DLinq本身绝对不是一套O/R M工具，不过利用它实现一套O/R M工具倒是不错的选择。 当面对面向对象和关系型数据库的阻抗失衡时，Java社区更多的考虑的是自动透明的实现将O映射成R的方式，而MS更多的考虑的是将R方便的变成O(数据包类型的O而已)的方式(这点可能跟MS也是数据库厂商有关)。两个方向，你选哪个？ 个人观点仅供参考。 You should use Hibernate if you have a nontrivial application (definition of nontrivial varies, but I usually think of Hibernate being less applicable to applications with only ten tables or so) that use an object-oriented domain model. Not every application needs a domain model, so not every application needs ORM. But if your application does a lot of business logic - rather than just displaying tabular data on a webpage - then a domain model is usually a good thing. Hibernate really starts to shine in applications with very complex data models, with hundreds of tables and complex interrelationships. For this kind of application, Hibernate will take away a huge amount of coding effort (perhaps up to 25%, for some applications) and will result in an application that performs better than the alternative handcrafted JDBC. This is possible because some kinds of performance optimizations are very difficult to handcode: caching, outer-join fetching, transactional write-behind, etc. |
|
|
