新的.NET 3.5项目:使用哪种DAL技术？

Question

我正在准备一个新的Windows项目,并想知道使用什么样的DAL技术.最初我在寻找一些更简单的东西,不花太多时间来构建它.但我也理解,从长远来看,它必须是高效和可扩展的.

我计划在3层系统上使用WPF(MVVM)客户端和WCF服务.

只是总结一下我熟悉的所有现有技术:

数据集

PRO:可能有点老式,但非常容易使用,让大多数部件为您自动生成.关于数据集的一个有力方面是通过关系遍历相关数据的便利性.此外,它还与数据库断开连接,并可能通过自动处理时间戳来简化更新.包括验证.

CONTRA:很老式.有些人认为它们不是真正的业务对象/模型,而只是SQL数据表的镜像.在WCF服务/客户端之间传递它们可能比自己创建的业务对象更难.

企业库4.1 - 数据访问块

PRO:DAL被精美地置于工厂模式中.它自动处理连接打开和关闭.在大多数情况下非常容易使用.它支持dataSet和普通SQL Sps来创建自己的Business对象.作为正在进行的框架的一部分,与企业库的其余部分结合使用可以更有效地获得高效的最终产品.

CONTRA:??

Linq to SQL

PRO:自动将SQL表创建为业务对象.易于CRUD.从理论上讲,这是一个非常好的方法.

CONTRA:在它出现时玩弄它,我发现它片状,有时不稳定.在微软宣布实体框架4.0(作为.NET 4.0的一部分)将是微软推荐的方式之后,它已经被认为是一种死技术.在.NET 4.0中只有少数错误修复,但没有更多功能扩展计划.

实体框架4.0

我对此一无所知,但只是因为它最终将取代.NET 4.0上的所有其他内容.我也很想使用它,但是由于它还在BETA中,我还是不能这样做.

我很想使用Enterprise Library 4.1 - 数据访问块并创建我自己的业务对象.大骗局是创建DAL需要更多时间.除非有人能说服我通过数据访问块使用DataSet.

你有什么意见和想法？非常感谢,Kave

Answer 1

您提到实体框架是 Linq to SQL 选项“反对”的一部分，但您应该考虑用它来代替 Linq to SQL —— 它提供几乎相同的功能以及更多功能。对于数据库较小的项目来说，它绝对物有所值。在 EF 中管理大型数据库的上下文可能具有挑战性，并且架构更改可能会导致事情中断，但任何数据访问方法都存在这些挑战。

在我看来，EntLib 最大的缺点是您仍在滚动自己的数据对象。企业库从直接的“老式”ADO.NET 实现中删除了许多管道代码，这很好，但它不会为您生成可开箱即用的 LINQ 查询数据对象。