申请：
我正在开发一个将用作产品的中型大型应用程序，我们需要决定我们的DAL层。应用程序UI位于Silverlight中，DAL层将位于服务层之后。我们也在推进域模型，因此我们的数据库表和域类没有相同的结构。所以像Data Mapper和Repository这样的模式肯定会出现。
我需要以优先级方式考虑下面提到的因素来设计DAL层
限制：
1）由于我们需要严格执行microsoft，我们不能使用NHibernate或除了EF 4.0之外的任何其他ORM
2）我们可以使用任何代码生成工具（应该是开源或非常便宜）但它应该只在.Net中生成代码，因此每个副本不会有任何许可问题。
问题
那么，你是否觉得我们应该继续使用EF 4.0，或者我们应该坚持使用ADO .Net并使用任何代码生成工具，如代码史密斯或任何其他你感觉最好的工具
此外，我还需要回答一些问题，比如将应用程序从EF 4.0移植到ADO .Net需要多长时间。如果将来我们遇到某些功能的EF 4.0，或者我们遇到了严重的性能问题。
反之，如果我们继续选择ADO .Net，那么什么时候开始使用EF 4.0
最后......我正在阅读文章，我发现只有代码方法（使用POCO类）似乎最适合我们的要求，因为从一种技术到其他技术的转换非常容易。
请分享您的想法并请指导上述问题
答案 0 :(得分：2)
使用EF4将为您节省很多的手动编码 - 或代码生成。仅这一点似乎是合理的使用它 - 最好的代码和唯一保证没有错误的代码是你不需要编写的代码。
EF4和NHibernate等是非常强大的工具，可以处理最苛刻和复杂的业务需求 - 例如数据库表中的继承等等。然而，它们确实增加了一些开销 - 而且它们并不总是易于学习和拾取。
所以我的挑衅性问题是：为什么不使用 Linq-to-SQL ？如果您只需要SQL Server作为后端，如果您的映射几乎总是在域模型中的表和类之间的1：1映射，这可能比使用EF4或NHibernate容易得多。
Linq-to-SQL肯定比EF4更容易，更快 - 它只是数据库上的一个相当薄的层。它比学习NHibernate容易得多 - 没有杂乱的映射语法可供学习，你可以通过视觉设计师获得支持。而且它很简单，你甚至可以进入那里并使用例如操纵代码生成。 T4模板（见Damien Guard的Linq-to-SQL templates）。
Linq-to-SQL即使在.NET 4 / VS 2010中也100％支持，因此它很可能仍然存在于VS2012中（或者下一个将被调用的任何东西）。因此，所有那些关于其消亡的世界末日预言都被夸大了 - 我不担心这是未来的证据。
更新： Linq-to-SQL和EF之间的一些性能比较：
一般来说，Linq-to-SQL似乎在查询性能上有优势，但EF似乎在更新方面做得更好。
答案 1 :(得分：1)
从哪里可以看出存储过程绑定DAL是正常的？我个人告诉他们就像15年前一样对于像市场上的任何ORM这样的系统（Hing：实体框架与nhibernate之类的东西比较糟糕）。我个人总是觉得好笑，除了MS“粉丝”之外的所有人都是ORM的东西。
即使考虑到实体框架的限制 - 它也比你手动提出的存储过程要好得多。
1：通常大约有40％到60％的代码处理数据库交互。这可以通过任何非愚蠢的ORM消除 - ＆gt;做数学。
2：见1.
3：好问题。遗憾的是，MS在数据访问领域做过非常愚蠢的事情。
4：很可能与手写的相同 - 在5％之内。可悲的是，你的贫血ORM（实体框架）没有实现任何真正有趣的功能（缓存等），所以不会自动获得休息收益。