Asp.Net中的数据访问层

Question

我很害怕如果我在这里做的过分。

我们最近为DAl，Services和DTO启动了一个.Net项目，包含不同的类库。

问题是关于我们的DAL层，我们想要一个干净且易于维护的数据访问层，我们希望使用Entity Framework 4.1。

因此，仍然不清楚使用DAO和DAOImpl methodolgy或 实体框架选择Plain ADO.Net的内容。 任何人都可以请建议最好的方法。

Answer 1

这取决于你想要多少工作投入到创建自己的定制DAL。使用ADO.NET和自己的实现总是更好，但是这也包括维护和优化它，并处理复杂情况，如并发，缓存以及BO，DAL和数据库的映射。

如果您想更专注于业务价值和功能，您可能会决定使用实体框架（现在4.3版本发布，5.0版本发布）。好处是您使用经过认真测试的DAL，并且已经包含并发，缓存和映射的解决方案。

但我几乎不会建议在它的顶部使用Repository和Unit Of Work模式来将实体框架的用法从其他图层中抽象出来。然后，您可以稍后完全更改底层技术，而不会对其他图层产生任何影响（如果您发现性能不如应有的效果，则可以用自己的ADO.NET实现替换EF）。

这取决于您需要构建的应用程序的类型及其性能要求。使用EF可以真正减少你的工作，并给你更快的结果。这也取决于开发团队的能力。如果您只有高级开发人员和架构师从事该项目，那么您将轻松创建自己的DAL。但对于初学者来说，要实现一个良好的，优化和强大的DAL是非常困难的。

我希望有帮助！

Answer 2

自从我记得以来，我一直在DAL中使用ADO.NET和DTO组合，并且我喜欢这个事实，即我控制创建实体和方法的整个过程。然而，这需要为每个存储过程的每个实体和方法编写类的代价。我不介意，但最近我发现了PLINQO for LINQ to SQL，我很喜欢它。它允许您根据数据库架构轻松创建/更新类，同时允许高级别的自定义。它基本上是类固醇上的LINQ2SQL。 我也很喜欢nHibernate但我认为它比PLINQO有更陡峭的学习曲线。

我给PLINQO一个尝试，如果我是你