放弃LINQ To SQL 、支持ORM框架 与 LINQ To Objects
一、LINQ To SQL 与ORM框架对比
【转】LINQ TO SQL和ORM的理解 http://developer.51cto.com/art/200909/151698.htm
LINQ To SQL和ORM的理解1、没有LINQ的源代码,不知道清楚中间的数据是如何处理的,特别是缓存是如何处理的。 LINQ To SQL和ORM的理解
2、用LINQ翻译到存储过程/Sql语句效率很低的,对于复杂的对效率有一定的要求的,还是要写存储过程。而且翻译出来的存储过程/Sql语句的怎么缓存,第二次执行的时候还要重新翻译,不能很好的利用缓存。 LINQ To SQL和ORM的理解
3、工具的支持。这一点是非常重要。如果没有有力工具的支持,用ORM简直就是恶梦。LINQ的工具支持总的来说,现在在VS2008里的支持我感觉还不是很友好。至少有一点,我们通常在表的备注里面写下这个字段的注释,很多情况下对应到界面上就是这个字段的抬头,这个工具不能直接生成到项目里去,因为我们不能控制,再者,现在的项目都不是由一个人完成,如果一个类有几十个字段,很难记住解释,自己的工具可以加入注释,方便开发。 LINQ To SQL和ORM的理解
4、与业务层的综合。通常ORM映射就是把对象与关系表之间形成映射关系,映射的目标是为了方便业务层的逻辑处理,如果不能与业务层无缝的结合起来,那么对于项目的开发,也未必有多少好处。至少在的ORM里面,与的我业务层可以非常友好的集成在一起。 LINQ To SQL和ORM的理解
5、多数据源的支持。对于我来说,这点也是非常关键的。我说的多数据源是指一个项目里面,有多个数据库,比如:基础数据、客户管理、业务运作、权限管理等,这些都是相对独立的模块,开发的时候,可以把这几个作为单独的项目开发,各自有自己独立的数据库,而且在多个项目里面,这些模块都是非常相似,像权限模块基本上是通用的,没有必要再重复开发。如果能够做到数据库层分离,则新项目开发的时候,可以达到更快的速度。当然也可以做到很容易的分合,把两个数据库合并成一个,或者把一个数据库分开成两个,只涉及到配置文件的更改,在开发的时候可以不关心的。 LINQ To SQL和ORM的理解
6、对于可变查询的处理。也就是相当于拼接字符串了。可能会说,这个是LINQ的强项,但是,如果对于一个分布式的项目呢?又应该如何处理。知道ORM的朋友应该都知道IBatis.net 和NHibnate ,I家的参数处理是非常的方便的,N家呢就没有I的直观,但是对于面向对象的处理I比N家好像就有太多的不足了。对于远程处理要能够通过参数传递这些只对映射层公开的参数,这点对于程序的某些地方可能是至关重要的影响。我的ORM里面,随便起了一个名字,叫通用查询,业务逻辑里用的查询通常会写在存储过程里,可以通过工具直接生成业务层代码里的函数。 LINQ To SQL和ORM的理解
7、对于泛形、继承的支持与处理。泛形,可以减少很多代码,同时,还可以减少很多人为的错误。因为人的精力总是有限的,你把精力花在一个地方,那么其他方面肯定关注的少了,我也一样。可能是我把精力过多的放在我的ORM里面,忽略了其他的方面,请大家能够给出批评指正。
总结一下 1、LINQ TO SQL 与传统的ORM框架(Ibatis.net、NHibernate)还是存在很大程度的差距。不适合支持大型企业开发 2、放弃LINQ TO SQL 不等于放弃 LINQ。 LINQ 对于领域模型的构建,会带来效率上的提升,简化相当代码量。
3、所以,相对比较好的企业级架构的一种方式,应该是ORM框架+领域(LINQ TO Objects)+ 外观(服务接口、DTO) + 展现层。强烈支持领域层灵活运用LINQ To Objsects