尽管微软的 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 的额外的映射能力。数据的转换、消息传递、以及数据推动是大多数大型应用程序中不可或缺的部分，框架可以使得这些工作能够以一个通用的方式易于实现与测试，从而带来高效的生产力。
查看英文原文： LINQ to SQL, The Next Step
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论