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

Posted 2023-02-24

【中文标题】新的 .NET 3.5 项目：使用哪种 DAL 技术？

【英文标题】：New .NET 3.5 Project: Which DAL technology to use?

【发布时间】：2010-12-21 09:38:50

【问题描述】：

我正在准备一个新的 Windows 项目，想知道使用哪种 DAL 技术。最初我正在寻找更简单的东西，而不是花费太多时间来构建它。但我也明白，从长远来看，它必须高效且可扩展。

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

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

数据集

PRO：可能有点过时，但非常易于使用，并且可以为您自动生成大部分部件。数据集的一个强大方面是通过关系轻松遍历相关数据。同样在某种程度上它与数据库断开连接，并且可以通过自动处理时间戳来简化更新。包括验证。

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

Enterprise Library 4.1 - 数据访问块

PRO：DAL 完美地融入了工厂模式。它负责自动打开和关闭连接。大多数情况下非常容易使用。它支持数据集和普通 SQL Sps 来创建您自己的业务对象。作为正在进行的框架的一部分，它与企业库的其余部分结合使用可以更高效地获得高效的最终产品。

对比：??

Linq to SQL

PRO：自动将 SQL 表创建到业务对象中。易于 CRUD。从理论上讲，这是一种非常好的方法。

CONTRA：当它出现时，我玩过它，我发现它很脆弱，有时不稳定。在 Microsoft 宣布 Entity Framework 4.0（作为 .NET 4.0 的一部分）将成为 Microsoft 推荐的方式之后，它已经被认为是一种死技术。在 .NET 4.0 中也只需要少量的错误修复，但没有更多的功能扩展计划。

实体框架 4.0

我对此一无所知，但我知道它最终会像 .NET 4.0 一样取代其他一切。我也很想使用它，但由于它仍处于 BETA 阶段，我还不能那样做。

我很想使用 Enterprise Library 4.1 - Data Access Block 并创建自己的业务对象。最大的缺点是创建 DAL 需要更多时间。除非有人可以说服我通过数据访问块来使用数据集。

你有什么想法和想法？ 非常感谢， 卡夫

【参考方案1】：

A.还要检查 NHibernate。

B. DataSet - 最快和最简单的，但是你写了很多代码。

所有其他的 - 使用 ORM 工具有很多好处，但是使用它们进行 3 层化有很多问题。

（延迟加载是一个需要处理的问题，造成很多影响性能的大对象树，缓存不是越智能越好）

所以 - 这取决于你的主要需求是什么，以及在开始编码之前你想花多少时间学习 EL/LINQ 或 NHibernate，b/c 这个工具有一个学习曲线。

【参考方案2】：

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

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

【讨论】：

我给了它一些想法，我认为你是对的。使用 EntLib 仍然意味着需要大量的工作来手动创建所有内容。当您提到 EF 时，您是指版本 4.0 BETA 还是实际版本 1.0？昨晚我实际上一直在尝试 1.0 版，我必须说它看起来很不错并且可以完成工作。就在此之前，我尝试了 SubSonic，它未能为我的查找表创建代码，该代码与其现有字段之一具有相同的名称。这一定让亚音速感到困惑。 EF 1.0 完美地完成了这项工作，我想我会这样做。你怎么看？

EF 1 远没有 LinqToSql 那样丰富的功能，而且 LinqToSql 在功能方面非常差。 EF 1 缺少对基本 ORM 概念的支持，例如适当的延迟加载支持，而 LinqToSql 确实支持。

我在一些应用程序中使用了 EF 1.0，这些应用程序具有较小的数据库并且对性能不重要，并且对它感到满意——基本要求是“将数据输入和输出”数据库”。如果功能、可扩展性和性能是一个大问题，您仍然可以尝试 EF，但可能希望使用另一个软件层或 CSLA 之类的东西抽象数据访问，以便您以后可以切换或升级数据访问技术。当然，到那时，RAD 的好处可能不再存在，您可能需要考虑一个完整的自定义堆栈。

嗨，伙计，距离 EF 4.0 发布还有不到 4 个月的时间，我想我现在可以专注于前端和业务层，并模拟 DAL 直到它发布。即使我现在必须去存储库，我还是决定坚持使用 MS 技术。考虑到 EF 4.0 甚至会将 nhibernate 赶走，花在第三方软件上的时间现在并不值得。由于延迟加载和异步数据加载对我来说很重要并且拥有简单的数据库架构，因此我认为我选择了 Linq2Sql 而不是 EF1.0。我相信 MS 会为我们提供转换向导以升级到 EF4

【参考方案3】：

我们以前使用 DataSet 和 EntLib 4.1 数据应用程序块。

我们现在使用实体框架。与 EntLib 4.1 相比，我们使用 Entity Framework 在生产力方面取得了巨大的进步。 （在 10 小时内为 80 个表编程数据层，而不是 80 个）

Entity Framework 4 仍处于测试阶段，但如果您的项目需要一段时间才能上线，我会选择 EF 4。您可以获得 ORM 的生产力，同时使用 POCO（Plain Old Clr）的灵活性对象）

【讨论】：

感谢您分享您的经验。您使用的是 EF 1.0 还是 EF 4.0 Beta？

@Kave，它是 EF 1.0，但我们在它处于测试阶段时开始使用它

【参考方案4】：

最好的办法是有机会同时使用这两种技术。 你怎么能这样做？存储库模式非常简单。 首先，您需要创建通用 IRepository 接口。像这样的东西：

public interface IERepository<E>

    DbTransaction BeginTransaction();
    void EndTransaction();
    void Add(E entity);
    void Delete(E entity);
    int Save();

    ObjectQuery<E> DoQuery(string entitySetName);
    IList<E> SelectAll(string entitySetName);
    E SelectByKey(int Key);

    bool TrySameValueExist(string fieldName, object fieldValue, string key);
    bool TryEntity(ISpecification<E> selectSpec);

    int GetCount();
    int GetCount(ISpecification<E> selectSpec);
    int AddAndSave(E entity);

我更喜欢实体框架。我基于它创建了 3 个项目。它工作得非常快，尤其是带有分页的查询。 因此，在您需要使用实现 IRepository 接口的虚拟方法创建基通用类 Repository 之后。就这样。 现在你有非常快速的方法来创建 DAl 编写简单的代码，如下所示：

public class MonthRepository:Repository<Month>

您可以覆盖基类的所有方法，并在需要的地方使用存储过程创建对 DB 的访问。而且您可以在不更改其他地方的代码的情况下使用。您仍将返回相同类型的实体，但会以其他方式获取它们。

阅读更多http://www.codeproject.com/KB/database/ImplRepositoryPatternEF.aspx

【讨论】：

谢谢伙计。如果它能让我更灵活地交换存储库，那么这个解决方案听起来确实很有趣。不过，我仍然需要先了解它。请给我几天工作后学习它。 ;o)

【参考方案5】：

NHibernate 在功能集、成熟度和支持方面具有最佳的整体组合。

NHibernate, Entity Framework, active records or linq2sql

对于您考虑的任何解决方案，您都应该优先考虑支持 Linq，并且您上面的前两个选项不支持 Linq。

【讨论】：

嗨，迈克尔，我也在阅读有关 NHibernate 的信息。我发现文档不是那么直接，而且它似乎是一个运行起来非常复杂的应用程序。除非您知道一些我还不知道的遍历网站，否则我会在那里感到有些失落。不幸的是，由于一个错误，SubSonic 对我不起作用。我仍然可以尝试 Castle Project，或者坚持使用 MS 解决方案，例如 EF 1.0，希望一旦可用就尽快升级到 v4.0。

如果您无法在 NHibernate 中找到自己的方法，那么您也不太可能从 LinqToSql 或 EntityFramework 获得所需的东西。 NHibernate 的文档并不比任何其他 ORM 的文档差。任何 ORM 都有一个学习曲线，NHibernate 的曲线目前刚刚开始。 NHibernate 很可能满足您的要求，而其他的可能只满足您的要求，直到某个点，然后您最终还是从 NHibernate 重新开始。归根结底，这是您的决定和责任。

谢谢迈克尔。您如何看待 Fluent NHibernate？自动为我生成映射是一种向导吗？是否有任何帮助工具可以让 NHibernate 的生活更轻松？

Fluent NHibernate 不进行任何代码生成，但它允许您使用 C# 而不是 XML 进行映射。请参阅此处了解 NHibernate 代码生成选项：***.com/questions/1703254/nhibernate-code-generation CodeSmith 似乎是目前最好的选择。