Delphi 下都用什么 O/R Mapping 框架
若以下回答无法解决问题,邀请你更新回答
1个回答
展开全部
近日 有关o/r m的讨论突然多了起来.在这里觉得有必要澄清一些概念,免的大家讨论来讨论去,才发现最根本的理解有问题.本文并不保证所有观点正确,只是个人在某一特定时期的理解.
1.何谓Entity?
实体(类似于j2ee中的Entity Bean)通常指一个承载数据的对象,但是注意它也是可以有行为的!只不过它的行为一般只操作自身的数据.比如下面这个例子:
class Person
{
string firstName;
string lastName;
public void GetName()
{
return lastName+firstName;
}
}
GetName就是它的一个行为.
2 何谓Domain Object?
对象最重要的特性在于它拥有行为.仅仅拥有数据,你可以称它为对象,但是它却失去它最重要的灵魂.
class Person
{
string firstName;
string lastName;
Role role;
int baseWage;
public void GetSalary()
{
return baseWage*role.GetFactory();
}
}
这样需要和别的对象(不是Value Object)打交道的对象,我就不再称其为实体.领域模型就是指由这些具有业务逻辑的对象构成的模型.
3.E/R M or O/R !
仔细想想我们为什么需要o/r m,无非是想利用oo的多态来处理复杂的业务逻辑,而不是靠一堆的if else.
而现在在很多人的手上o/r m全变成了e/r m.他们不考虑对象的行为,而全关注于如何保存数据.这样也难怪他们会产生将CRUD这些操作放入对象中的念头.如果你不能深刻理解oo,那么我不推荐你使用o/r m,Table Gateway,Row Gateway才是你想要的东西.
作为一个O/R M框架,很重要的一点就是实现映射的透明性(Transparent),比较显著的特点就是在代码中我们是看不到SQL语句的(框架自动生成了),但是这并不是透明性的实质,详见Enterprise Persistence Design,这里所指的O/R M就是类似于此的框架.
4.POEAA中的相关概念
很多次发现有人错用其中的概念,这里顺便总结一下:
1.Table Gateway
以表为单位的实体集合,基本没有行为,只有CRUD操作.
2.Row Gateway
以行为单位的实体,基本没有行为,只有CRUD操作.
3.Active Record
以行为单位的实体,拥有一些基本的操作自身数据的行为(如上例中的GetName),同时包含有CRUD操作.
其实Active Record最符合某些简单的需求,接近于E/R m.
通常也有很多人把它当作O/R m.不过需要注意的是Active Record中是充满了SQL语句的(不像orm的SQL透明),所以有人想起来利用O/R m来实现"Active Record",虽然在他们眼里看起来很方便,其实根本就是返祖.
用CodeGenerator来实现Active Record也许是一个比较好的方法.
4.Data Mapper
这才是真正的O/R m,Hibernate等等工具的目标.
5.O/R M需要关注的地方 (希望大家帮忙完善一下)
1.关联以及与此相关的Lazy Load,O/R M是如何管理类之间的关联.当然这不仅于O/R M有关与设计者的设计水平也有很大关系.
2.O/R M对继承关系的处理.
3.O/R M对事务的支持.
4.O/R M对查询的支持.
以上观点仅属个人意见,不过在大家讨论有关O/R M之前,希望先就一些基本概念达成共识,不然讨论下去会越离越远.
1.何谓Entity?
实体(类似于j2ee中的Entity Bean)通常指一个承载数据的对象,但是注意它也是可以有行为的!只不过它的行为一般只操作自身的数据.比如下面这个例子:
class Person
{
string firstName;
string lastName;
public void GetName()
{
return lastName+firstName;
}
}
GetName就是它的一个行为.
2 何谓Domain Object?
对象最重要的特性在于它拥有行为.仅仅拥有数据,你可以称它为对象,但是它却失去它最重要的灵魂.
class Person
{
string firstName;
string lastName;
Role role;
int baseWage;
public void GetSalary()
{
return baseWage*role.GetFactory();
}
}
这样需要和别的对象(不是Value Object)打交道的对象,我就不再称其为实体.领域模型就是指由这些具有业务逻辑的对象构成的模型.
3.E/R M or O/R !
仔细想想我们为什么需要o/r m,无非是想利用oo的多态来处理复杂的业务逻辑,而不是靠一堆的if else.
而现在在很多人的手上o/r m全变成了e/r m.他们不考虑对象的行为,而全关注于如何保存数据.这样也难怪他们会产生将CRUD这些操作放入对象中的念头.如果你不能深刻理解oo,那么我不推荐你使用o/r m,Table Gateway,Row Gateway才是你想要的东西.
作为一个O/R M框架,很重要的一点就是实现映射的透明性(Transparent),比较显著的特点就是在代码中我们是看不到SQL语句的(框架自动生成了),但是这并不是透明性的实质,详见Enterprise Persistence Design,这里所指的O/R M就是类似于此的框架.
4.POEAA中的相关概念
很多次发现有人错用其中的概念,这里顺便总结一下:
1.Table Gateway
以表为单位的实体集合,基本没有行为,只有CRUD操作.
2.Row Gateway
以行为单位的实体,基本没有行为,只有CRUD操作.
3.Active Record
以行为单位的实体,拥有一些基本的操作自身数据的行为(如上例中的GetName),同时包含有CRUD操作.
其实Active Record最符合某些简单的需求,接近于E/R m.
通常也有很多人把它当作O/R m.不过需要注意的是Active Record中是充满了SQL语句的(不像orm的SQL透明),所以有人想起来利用O/R m来实现"Active Record",虽然在他们眼里看起来很方便,其实根本就是返祖.
用CodeGenerator来实现Active Record也许是一个比较好的方法.
4.Data Mapper
这才是真正的O/R m,Hibernate等等工具的目标.
5.O/R M需要关注的地方 (希望大家帮忙完善一下)
1.关联以及与此相关的Lazy Load,O/R M是如何管理类之间的关联.当然这不仅于O/R M有关与设计者的设计水平也有很大关系.
2.O/R M对继承关系的处理.
3.O/R M对事务的支持.
4.O/R M对查询的支持.
以上观点仅属个人意见,不过在大家讨论有关O/R M之前,希望先就一些基本概念达成共识,不然讨论下去会越离越远.
本回答被提问者和网友采纳
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询