ORM模式

博客园在推广ORM方面的确做了很大的贡献,很多的程序员开始使用ORM,不用写SQL的喜悦让他们激动不已,可是好景不长,他们很快发现众多的烦恼一个接一个的出现了。

很遗憾,我并不打算在这篇文章中解决这些问题,因为的确存在这些问题,而且目前没有完美的解决方法。那么既然这样,我们为什么要使用ORM呢?难道真的是为了不使用SQL吗?

还是要看O - R ,我们为什么要将关系型的数据转化成Object的方式,DataSet的方式难道不好吗?和数据库的表现还是很一致,又简单又方便,为什么先辈们要兴师动众的转化为Object。
我们知道,Object是可以继承的,是可以使用接口的,而Relation没有这个概念。就是因为这一点,我们将实体设计成Object方法,从而获取了大量的优势。
例如:我可以在程序中检测实体是否支持IVersionObject接口,如果支持,我们将自动做版本控制,而如果你给我一个DataSet,那我将无法检测(不要告诉我检测是否存在Version字段)。通过这个特性我们将可以自动化处理很多的事情。
又如,我设计了一个单据实体的基类,包含了SheetCode、SheetDate等等字段,然后我的OrderSheet继承自SheetBase,他们将自动获取到这些标准的字段,而且我的基础类可以自动帮助我处理很多统一的规则,使程序更加稳健和统一。而这个Relation的东西是非常难做到的。

市面上有很多的ORM系统,鱼龙混杂,事实上,相当多的系统根本无法利用Object的继承特性,他们还是一堆的如何做一对多、多对多的概念。根本没有了解到ORM的精髓就做出来。

在这里我需要解释几个误解:
1、ORM使我们摆脱了SQL,但并不代表我们不再使用SQL,事实上,复杂的查询和报表我仍然推荐使用SQL,良好的系统应该可以兼容以前的方式;
2、微软在表模型(Relation)上花费了无数的精力,所以目前Relation的一揽子解决方案是最完整,最好的。但我们看到,微软在.NET 2.0中对Object方式的绑定支持更近了一步,随着LinQ、XAML等很多后续技术的发展,相信领域模型(Object)的完整解决方案将更加完整;

3、ORM更适合复杂的系统(这里使用复杂,而不是大型),而不是小的系统,因为这样的系统要求建造速度快,系统稳定,他们的业务规则异常的复杂,但他们对系统的性能要求并不是很高(相对电信这样的性能要求)


  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
在一般的ORM(对象关系映射)中,常用到以下几种设计模式: 1. **工厂模式(Factory Pattern)**:ORM框架通常会提供一个工厂类,用于创建数据库连接、会话等对象。工厂模式可以隐藏对象的创建细节,提供统一的接口给用户使用。 2. **单例模式(Singleton Pattern)**:ORM框架中的某些组件,如数据库连接池、会话管理器等,需要保证全局只有一个实例。单例模式可以确保只有一个对象被创建,并提供全局访问点。 3. **原型模式(Prototype Pattern)**:ORM框架中的查询语句、实体映射等配置信息通常会被缓存起来,以提高性能。原型模式可以通过复制现有对象来创建新对象,避免重复创建和初始化配置信息。 4. **策略模式(Strategy Pattern)**:ORM框架需要支持不同的数据库类型和查询语言,而且可能会有不同的查询优化策略。策略模式可以将不同的算法封装成独立的策略类,并在运行时动态选择合适的策略。 5. **观察者模式(Observer Pattern)**:ORM框架中的实体对象通常会与数据库表进行双向映射,当实体对象发生变化时,需要及时更新数据库。观察者模式可以实现对象之间的一对多依赖关系,当被观察者对象状态发生变化时,通知所有观察者进行相应的操作。 6. **装饰器模式(Decorator Pattern)**:ORM框架可能需要对查询结果进行加工处理,如缓存、延迟加载等。装饰器模式可以动态地给对象添加额外的行为,而不需要修改原始对象的结构。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值