ORM之殇,我们需要什么样的ORM框架?_.NET

您所在的位置：程序员俱乐部 > 编程开发 > .NET > ORM之殇,我们需要什么样的ORM框架?

ORM之殇,我们需要什么样的ORM框架?

2015/3/20 21:07:53 hubro 程序员俱乐部我要评论(0)

摘要：最近在研究ORM,究竟什么样的框架才是我们想要的开发框架的意义在于开发更标准,更统一,不会因为不同人写的代码不一样开发效率更高,无需重新造轮子,重复无用的代码,同时简化开发流程运行效率得到控制,程序稳定性得到提高把网上关注比较多的框架搜了搜,作了个列表Nhibernate来源于Java的Hibernate参考:http://www.cnblogs.com/ylwn817/articles/1963528.htmlEntityFramework微软本家框架,都比较熟悉iBATIS
标签：什么我们什么样

最近在研究ORM,究竟什么样的框架才是我们想要的

开发框架的意义在于

开发更标准,更统一,不会因为不同人写的代码不一样
开发效率更高,无需重新造轮子,重复无用的代码,同时简化开发流程
运行效率得到控制,程序稳定性得到提高

把网上关注比较多的框架搜了搜,作了个列表

Nhibernate
来源于Java的Hibernate
参考:http://www.cnblogs.com/ylwn817/articles/1963528.html
Entity Framework
微软本家框架,都比较熟悉
iBATIS.NET
apache开源项目
参考:http://developer.51cto.com/art/200907/137796.htm
Nbear
博客园Teddy开发的项目
参考:http://www.cnblogs.com/teddyma/archive/2006/11/07/553562.html
Castle ActiveRecord
ActiveRecord是Hibernate的一个延伸
参考:http://terrylee.cnblogs.com/archive/2006/04/03/365762.html

加再上其他人写的一些框架,包括自已写的,大差不差

整理了一些常用的特性,对这些框架作一个评分

可编程性(语法支持) 我们希望不再用字符串的形式拼接SQL,并且能通过编译验证
class="Apple-tab-span">容错性可看作是上面扩充,不希望一个地方改了,其它地方没改,没任何提示,造成错误
开发效率包括框架的配置,开发过程
关联查询支持度关联查询是不可避免的
额外配置是否需要额外配置和第三方工具支持,影响开发效率
缓存支持能大大增强程序效率

跟数据库打交道,最重要的功能当属查询了,查询做得好不好直接影响易用度,Lambda和Linq方式为首选

下面是对这些框架的分析,没有仔细研究,可能不对,只代表个人意见,仅供参考

Nhibernate

新版Nhibernate增加了Lambda和Linq查询支持

Join好像也能实现了

var list1 = session.CreateCriteria<Product>()
    .Add(Restrictions.Eq("Discontinued", false))
    .Add(Restrictions.Eq("Category.Id", 2))
    .List<Product>();

对缓存支持也有,有多种实现方式
http://www.cnblogs.com/lyj/archive/2008/11/28/1343418.html

只是一如既往需要配置XML映射

Entity Framework

在上述特性中,除了没有缓存,EF都比较完美,关且在最新版7中,强制了CodeFirst模式,是其它框架没有的(这样更符合业务开发模式)

有的说EF太过庞大,用不好效率会有些问题,确实,特别是关联,写不好就弄出没效率的SQL语句,这也正是他可编程性太强的缘故,如果不是这么强,就不会这么写,会想想把结构好好设计设计

由于太过于对象的概念,默认不支持批量更新/删除

iBATIS.NET

除了有基本的对象映射优点只剩灵活来描述了,所有操作都需要配置XML文件来表示

﹤select id="GetAllAccountsAsHashMapViaResultMap" 
                resultMap="account-hashtable-result"﹥  
    select *  
    from Accounts  
    order by Account_ID  
﹤/select﹥

好像还支持缓存

﹤select id="GetCachedAccountsViaResultMap" 
            resultMap="account-result" 
            cacheModel="account-cache" ﹥  
    select *  
    from Accounts  
    order by Account_ID  
﹤/select﹥

这已经不属于面向对象,就是一个查询映射

Nbear

Nbear可以通过对象的方式自动映射对象关联,但不能直接关联查询
条件查询,参数化,不太智能,好像好长时间没更新了,不知现在是怎么查

LocalUser[] users = gateway.Select<LocalUser>(_Entity.LocalUser.Id > 5 | _Entity.LocalUser.LoginId == "teddy", _Entity.LocalUser.Id.Desc & _Entity.LocalUser.LoginId.Asc);

可以使用配置的方式支持缓存,好像只能单个表

<cacheConfig enable="true">
    <cachingTables>
      <add key="Northwind.Orders" value="5" />
    </cachingTables>
 </cacheConfig>

除了表映射外,还支持视图,存储过程映射,(这个其实已经脱离面向对象的概念了,设计好的业务对象,对这基本没需求)
对象定义是接口类型,不明白

public interface IdentableEntity : IEntity

       {

           [PrimaryKey]

           int Id { get; set; }

           string Name { get; set; }

       }

Castle ActiveRecord

ActiveRecord延伸于hibernate,少不了一堆数据库配置

也支持关联对象,通过属性定义

  [HasMany(typeof(Post), Table="posts", ColumnKey="post_blogid")]

    public IList Posts

    {

        get { return _posts; }

        set { _posts = value; }

    }

查询方式为方法传参,比较原始,不知最新的没有引入Linq和Lambda
http://terrylee.cnblogs.com/archive/2006/04/12/372823.html

SimpleQuery query = new SimpleQuery(

            typeof(Post),typeof(int),

           @"select post.Id from Post post where post.Created between ? and ?",

            start,end

);

综合起来

可编程性(语法支持) 容错性 开发效率 关联查询支持度 额外配置 缓存支持 Nhibernate Linq&Lambda语法高中中映射需要配置XML 支持 Entity Framework Linq&Lambda语法高高高不支持 iBATIS.NET 无低低高 XML配置查询支持 Nbear 运算符重载高中中需要工具生成类支持 Castle ActiveRecord 无低中中支持