.NET 对象持久性选项答案

【问题标题】：.NET Object persistence options.NET 对象持久性选项
【发布时间】：2011-01-23 19:43:37
【问题描述】：

我有一个问题，我觉得我没有找到令人满意的答案，或者我没有找到正确的地方。

我们的系统最初是使用 .NET 1.1 构建的（但是现在所有项目都支持 3.5），所有实体都使用存储过程和具有标准 ExecuteReader、ExecutreNonQuery 类型方法的“SQLHelper”持久保存到数据库中。

所以通常情况下，我们将拥有我们的实体，例如 User 和 Role，我们将拥有另一个名为 UserIO 的类，它使用以下方法将这些对象持久保存到数据库中：

 static UserIO.SaveUser(User user)

单独的IO文件的原因是为了保持IO与实体分开但是仅仅调用不是更令人满意吗？：

User.Save()

也许我错了，但将这些“IO”文件分散在各处感觉不合适。所以我正在考虑寻找其他持久性选项，我想知道从哪里开始最好。我过去使用过数据集，但有一些复杂的经验，尤其是它们的性能。我知道 LINQ 现在已经存在，但我听说我应该使用 ADO.NET Entity Framework 而不是 LINQ，但后来有人告诉我 Entity Framework 不太正确，我应该等待 C# 4.0。如果是这种情况，并且 C# 4.0 即将到来，我是否应该继续我的“IO”文件方法，并在 C# 4.0 最终发布时从实体框架开始。或者是否有我可以使用的更优雅的类结构，例如使用部分类？

我应该说，我不打算完全替换已经存在的数据访问，我更关心我正在创建的新实体。

如果这个问题有点笼统，我很抱歉，但是我周围没有多少人可以反驳这种想法。

【问题讨论】：

标签： c# sql-server data-access-layer object-persistence

【解决方案1】：

我已经成功使用了 Entity Framework 3.5。有些人，我认为他们是纯粹主义者，他们认为 Entity Framework 违反了某些规则，不应该使用。

在我看来，唯一重要的规则是你自己的。我建议您开始尝试使用 Entity Framework 3.5，因为您现在拥有它。此外，您（以及几乎所有其他人）需要尽快开始试验 .NET 4.0。 Release Candidate 是免费提供的，所以没有理由不知道有什么可用。

您可能会发现自己非常喜欢 4.0 中的 EF 更改，以至于您想要等待它。就像 3.5 中一样，您可能不需要等待，并且可以继续从 EF 中受益。我有，我很高兴我没有等到。

【讨论】：

感谢您不要完全忽略 EF，这是一个很好的鼓励。一直想把 RC 看作是一切，尽管它正在寻找时间！您会说 EF 适合与我们现有的数据访问一起使用吗？我的问题与@LBushkin 的问题非常相似。谢谢埃德
@MrEdmundo：我已经在生产应用程序中成功使用了 EF 3.5。在我看来，它的问题很少，而且很小。

【解决方案2】：

如果您正在寻找对象关系映射模型，您可以查看：

这里还有一个更长的列表：http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software#.NET

至于如何为持久化设计一个对象模型这个一般性问题，大部分设计选择取决于系统的复杂性，你需要的可扩展性，是否需要支持多重持久化存储（SQLServer、Oracle、文件系统等）等等。您描述的模式看起来像DataTansferObject (DTO)。这是将持久性逻辑与业务逻辑分离的常见设计。

顺便说一句，良好系统设计的一般原则是single responsibility principle。 在构建系统时，您必须确定将不同的职责组合到一个类中是否有意义。结合职责通常会使系统复杂化并产生难以解决的设计冲突。

【讨论】：

感谢您在冗长的描述中加上名字:)。您认为您所描述的映射模型类型适合在产品生命周期的后期出现（如我的情况），还是更适合基础开发？
视情况而定。一些图书馆更擅长使用 POCO，而其他图书馆则不然。需要消费者实现大量接口或从特定基类继承的库显然更难在游戏后期引入项目。例如，NHibernate 相对擅长使用 POCO——因此您甚至可以在项目后期使用它。但是，请记住 - 对于实施的一致性，有一些话要说。在应用程序中使用多种不同的方式来持久化数据可能不利于长期维护或开发人员入职。

【解决方案3】：

我经常使用的模式是：每个对象都有以下内容：

数据传输对象 (DTO) - 这可以使数据集使用的内存尽可能小。
业务对象 - 至少将上述 DTO 作为构造函数 - 这将在 DTO 上执行任何不是 CRUD 函数的函数
存储库类中的 CRUD / 持久方法

后者可以通过以下两种方式之一完成。你可以有一个大的存储库类，这对于只有几个对象的应用程序/组件来说很好，或者你可以为每个对象有单独的存储库。

看看 Rudy Lacovaras 博客。他最近发表了一系列关于使用类似模式进行高效数据访问的文章。

【讨论】：

【解决方案4】：

拥有一个独立于模型的存储库是一种常见的模式。对于这种模式，名称 IO 是唯一的，但有效。现在，根据您与谁交谈（想到 TDD 疯子），您可能会因为使用静态类而感到沮丧。

【讨论】：

【解决方案5】：

拥有一组实现数据功能的类通常称为分层编程。 (http://en.wikipedia.org/wiki/N-tier)。通过分离访问数据层的类，您可以创建一个更易于维护的系统。如果您将这些功能合并到在应用程序中实现业务规则的类中，您将失去多层设计的许多优势。

将数据访问函数分配到它们自己的类中是好的（为设计者喝彩 3 次），但是将它们分布在整个地方是不好的。理想情况下，您不会将这些函数的来源都放在同一个目录或文件中（取决于项目大小）。如果它们都在一起，您将获得许多优势。将它们分成（随机？）许多位置违背了模块化此代码的目的。

【讨论】：