如果我在这里过度的话，我很害怕。
我们最近启动了一个.Net项目，为DAl，Services和DTO包含不同的类库。
问题是关于我们的DAL层，我们想要一个干净且易于维护的数据访问层，我们想要使用Entity Framework 4.1。
所以仍然不清楚使用DAO和DAOImpl methodolgy或者选择什么选择Plain ADO.Net 实体框架。 任何人都可以建议最好的方法。
答案 0 :(得分：1)
这取决于您想要创建自己的自定义DAL的工作量。使用ADO.NET和您自己的实现总是更好，但这还包括维护和优化它以及处理复杂的情况，例如并发，缓存以及BO，DAL和数据库的映射。
如果您想更多地关注业务价值和功能，您可能会决定使用Entity Framework（现已发布4.3版本和5.0版本）。优点是您使用经过仔细测试并且已包含并发，缓存和映射解决方案的DAL。
但我不建议在其上使用Repository和Unit Of Work模式来抽象Entity Framework的用法。然后，您可以在以后完全更改底层技术而不会对其他层产生任何影响（如果您发现性能不如它应该的那么好，您可以用自己的ADO.NET实现替换EF）。
这取决于您需要构建的应用程序类型及其性能要求。使用EF可以真正减少您的工作并为您提供更快的结果。它还取决于开发团队的能力。如果您只有高级开发人员和架构师参与该项目，那么您将轻松创建自己的DAL。但对于初学者来说，实现一个优秀，优化和强大的DAL真的很难。
我希望有所帮助！
答案 1 :(得分：0)
自从我记得以来，我一直在DAL中使用ADO.NET和DTO组合，我喜欢这样一个事实，即我控制着创建实体和方法的整个过程。然而，这需要为每个存储过程的每个实体和方法编写类的代价。我不介意，但最近我发现PLINQO for LINQ to SQL，我很喜欢它。它使您可以根据数据库模式轻松创建/更新类，同时允许高级别的自定义。它基本上是类固醇的LINQ2SQL。 我也喜欢nHibernate，但我认为它比PLINQO有更陡峭的学习曲线。
如果我是你，我会试试PLINQO