我害怕如果我在这里做太多事情。
我们最近启动了一个 .Net 项目，其中包含用于 DAl、服务和 DTO 的不同类库。
问题是关于我们的 DAL 层，我们想要一个干净且易于维护的数据访问层，我们想要使用 Entity Framework 4.1。
所以仍然不清楚使用 DAO 和 DAOImpl 方法选择 Plain ADO.Net 或 实体框架。 任何人都可以建议最好的方法。
【问题讨论】：
标签： c#-4.0 architecture ado.net data-access-layer
这取决于您要投入多少工作来创建自己的自定义 DAL。使用 ADO.NET 和您自己的实现总是更好，但这也包括维护和优化它以及处理复杂情况，例如并发、缓存以及您的 BO、DAL 和数据库的映射。
如果您想更多地关注业务价值和功能，您可能会决定使用 Entity Framework（现已发布 4.3 和 5.0）。这样做的好处是您使用了经过仔细测试并且已经包含并发、缓存和映射解决方案的 DAL。
但我几乎不建议在它之上使用存储库和工作单元模式来将实体框架的使用从其他层中抽象出来。然后，您可以稍后完全更改底层技术，而不会对其他层产生任何影响（例如，如果您发现性能不如预期的那么好，您可以用您自己的 ADO.NET 实现替换 EF）。
这取决于您需要构建的应用程序类型及其性能要求。使用 EF 确实可以减少您的工作量并更快地获得结果。它还取决于开发团队的能力。如果您只有高级开发人员和架构师从事该项目，那么您将轻松创建自己的 DAL。但是对于初学者来说，要实现一个好的、优化的和健壮的 DAL 真的很难。
希望对你有帮助！
【讨论】：
自从我记得以来，我一直在 DAL 中使用 ADO.NET 和 DTO 组合，我喜欢我控制创建实体和方法的整个过程的事实。然而，随之而来的代价是必须为每个实体编写类，为每个存储过程编写方法。我不介意，但最近我发现了PLINQO for LINQ to SQL，我很喜欢它。它使您可以轻松地根据您的数据库模式创建/更新类，同时允许进行高级别的自定义。它基本上是类固醇上的 LINQ2SQL。 我也喜欢nHibernate，但我认为它的学习曲线比 PLINQO 更陡峭。
如果我是你，我会试试 PLINQO
【讨论】：