LINQ to SQL何去何从？(摘抄）

 

尽管微软的ORM存在许许多多的问题，而且市面上例如LLBLGen，nHibernate与OpenAccess之类的替代品已经够多了，许多开发者被强迫使用微软的技术是因为他们的公司或客户的需要。而在取舍之间，看起来大多数开发者深信实体框架（Entity Framework）并非可行的方案。那么他们该如何应对？
Steel Price选择忘记Linq to Sql的衰亡，继续使用它是因为它能工作。至于实体框架，他写道，它并不能访问内在的列。

我永远都不会使用这样的一种联合关系，譬如：“给我提供John修改过的所有地址”。这会使得事情变得糟糕，我无法获得Address的CreatedById，除非我加载整个Login对象，并像这样引用它：Address.CreatedByLogin.LoginId。当你在编写和创建查询时，这种做法就太糟糕了。
有办法解决这个问题吗？当然有，但方法都过于复杂与繁琐，使用L2E（译注：即Linq to Entity）使得我80%的工作都变复杂了。而只有20%的功能是我真正需要额外的进行复杂的映射，但我可以使用其它工具，例如LLBLGen Pro或OpenAccess，因为它们更易于使用。

C# MVP David Hayend则说出了大多数开发者的心声，那就是让LINQ to SQL开源。他更进一步地建议LINQ to SQL应该采取ASP.NET MVC相同的方式，源自于社区的设计。

我强烈建议微软为LINQ To SQL重新组建最初的开发团队，并将他们融入到.NET 4.0版本中，并以开源的方式放在CodePlex上。这别无选择，鉴于LINQ To SQL已经明显偏向于实体框架，只有ADO.NET团队能够为他找到正确的方向。
我建议新的团队采取和ASP.NET MVC团队相似的方式，使我们能够获得一个可测试的轻量级O/R映射器，并关注于持续获得的社区反馈而频繁发布CTP版本。

Ian Cooper, another MVP, sees neither LINQ to SQL nor Entity Framework being completely suitable,
另一位MVP Ian Cooper则认为LINQ to SQL和实体框架都不完全适用。

简单地靠打压竞争者很难挽救我们对EF（译注：即实体框架Entity Framework）信心的缺乏。我们需要对批评进行更加深入地理解，但是那些说法并不能指出LINQ To SQL比EF好在哪些地方。L2S具有很多EF非常需要的特性，例如领域优先支持、POCO、SQL生成的性能、延迟加载等。如果缺乏对这些优势的公共认识，怀疑则必然延续，这无关ADO.NET是否认识到LINQ To SQL为何具有这般正面的支持。

直接抛弃LINQ to SQL并不可取，他建议微软承认已经犯下的过错，并基于二者的优势重新开始。

更好的结果应该是看到微软宣布开发LINQ To SQL和实体框架共同的继承者。从产品中获得反馈，然后再构建一个新的，可以称之为“LINQ to Relations”或者“LINQ to RDBMS”。如果确有所需，保证重用能够使你节约费用，但却需要重新计划。我无法想象的是，无论如何，比起L2S和EF开发人员需要在你的ORM下一次迭代中需要面对的问题而言，API的变化要显得更加的重要。
[…]
大多数人赞同Faulkner的建议并且正试图抛弃你曾经的最爱。有时候，你投入的特性越多，而越有可能在最后需要重新计划。
那么，就应该及早发布，并且应频繁发布。

最后，Scott Allen的问题则重点放在数据库上。

我认为，LINQ to SQL的内部能够从一个好的基础发展为一个通用的数据映射框架，以弥补ORM类型的框架（如Entity Framework）的不足。框架可以去掉一些有关对象到对象映射的繁重工作，或者通过一个提供者类型的架构提供在不同格式之间如XHTML、JSON、CSV的额外的映射能力。数据的转换、消息传递、以及数据推动是大多数大型应用程序中不可或缺的部分，框架可以使得这些工作能够以一个通用的方式易于实现与测试，从而带来高效的生产力。