放弃LINQ To SQL 、支持ORM框架 与 LINQ To Objects

放弃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的理解１、没有LINQ的源代码，不知道清楚中间的数据是如何处理的，特别是缓存是如何处理的。 LINQ To SQL和ORM的理解

２、用LINQ翻译到存储过程/Sql语句效率很低的，对于复杂的对效率有一定的要求的，还是要写存储过程。而且翻译出来的存储过程/Sql语句的怎么缓存，第二次执行的时候还要重新翻译，不能很好的利用缓存。 LINQ To SQL和ORM的理解

３、工具的支持。这一点是非常重要。如果没有有力工具的支持，用ORM简直就是恶梦。LINQ的工具支持总的来说，现在在VS2008里的支持我感觉还不是很友好。至少有一点，我们通常在表的备注里面写下这个字段的注释，很多情况下对应到界面上就是这个字段的抬头，这个工具不能直接生成到项目里去，因为我们不能控制，再者，现在的项目都不是由一个人完成，如果一个类有几十个字段，很难记住解释，自己的工具可以加入注释，方便开发。 LINQ To SQL和ORM的理解

４、与业务层的综合。通常ORM映射就是把对象与关系表之间形成映射关系，映射的目标是为了方便业务层的逻辑处理，如果不能与业务层无缝的结合起来，那么对于项目的开发，也未必有多少好处。至少在的ORM里面，与的我业务层可以非常友好的集成在一起。 LINQ To SQL和ORM的理解

５、多数据源的支持。对于我来说，这点也是非常关键的。我说的多数据源是指一个项目里面，有多个数据库，比如：基础数据、客户管理、业务运作、权限管理等，这些都是相对独立的模块，开发的时候，可以把这几个作为单独的项目开发，各自有自己独立的数据库，而且在多个项目里面，这些模块都是非常相似，像权限模块基本上是通用的，没有必要再重复开发。如果能够做到数据库层分离，则新项目开发的时候，可以达到更快的速度。当然也可以做到很容易的分合，把两个数据库合并成一个，或者把一个数据库分开成两个，只涉及到配置文件的更改，在开发的时候可以不关心的。 LINQ To SQL和ORM的理解

６、对于可变查询的处理。也就是相当于拼接字符串了。可能会说，这个是LINQ的强项，但是，如果对于一个分布式的项目呢？又应该如何处理。知道ORM的朋友应该都知道IBatis.net 和NHibnate ，I家的参数处理是非常的方便的，N家呢就没有I的直观，但是对于面向对象的处理I比N家好像就有太多的不足了。对于远程处理要能够通过参数传递这些只对映射层公开的参数，这点对于程序的某些地方可能是至关重要的影响。我的ORM里面，随便起了一个名字，叫通用查询，业务逻辑里用的查询通常会写在存储过程里，可以通过工具直接生成业务层代码里的函数。 LINQ To SQL和ORM的理解

７、对于泛形、继承的支持与处理。泛形，可以减少很多代码，同时，还可以减少很多人为的错误。因为人的精力总是有限的，你把精力花在一个地方，那么其他方面肯定关注的少了，我也一样。可能是我把精力过多的放在我的ORM里面，忽略了其他的方面，请大家能够给出批评指正。

 

总结一下 1、LINQ TO SQL 与传统的ORM框架（Ibatis.net、NHibernate）还是存在很大程度的差距。不适合支持大型企业开发 2、放弃LINQ TO SQL 不等于放弃 LINQ。 LINQ 对于领域模型的构建，会带来效率上的提升，简化相当代码量。

3、所以，相对比较好的企业级架构的一种方式，应该是ORM框架+领域（LINQ TO Objects）+ 外观（服务接口、DTO） + 展现层。强烈支持领域层灵活运用LINQ To Objsects