.NET对象持久化选项

Question

我有一个问题，但我感觉自己还没有找到满意的答案，或者我没找对地方。

我们的系统最初是使用.NET 1.1构建的（但现在所有项目都支持3.5），并且所有实体都使用存储过程和一个名为“SQLHelper”的工具类进行数据库持久化，该类具有标准的ExecuteReader、ExecutreNonQuery等方法。

通常情况下，我们会有一些实体，例如 User 和 Role，然后还有另一个称为 UserIO 的类，它使用像以下这样的方法将这些对象持久化到数据库中:

 static UserIO.SaveUser(User user)

将IO文件与实体分开的原因是为了保持IO的独立性，但是否更令人满意的方法只是简单地调用呢？

User.Save()

也许我错了，但是将这些"IO"文件散布在各处感觉不太对。因此，我正在考虑寻找其他持久性选项，并想知道最好的起点在哪里。我过去使用过数据集，但其中有些是负面经验，特别是它们的性能。我知道现在有LINQ，但我听说我应该使用ADO.NET实体框架，而不是LINQ，但是其他人告诉我实体框架还不太成熟，我应该等待C# 4.0。如果是这样，那么在C# 4.0即将发布之际，我是否应该继续采用我的“IO”文件方法并从实体框架入手？或者，也许我可以使用更优雅的类结构，比如利用Partial Classes？

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

如果这个问题有点笼统，我很抱歉，因为我周围没有多少人可以交流这种想法。

- MrEdmundo

Answer 1

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

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

可能你会发现你非常喜欢EF 4.0中的更改，以至于你想等待它。同样有可能你不觉得需要等待，并且可以直接从EF 3.5中受益。我已经这样做了，我很高兴我没有等待。

- John Saunders

---

谢谢，这是一些很好的鼓励，不要完全忽视 EF。一直想看看 RC，但像所有事情一样，时间太紧了！你会说 EF 是否适合与我们现有的数据访问一起使用吗？我的问题与 @LBushkin 的问题非常相似。谢谢，Ed。 - MrEdmundo

@MrEdmundo：我已经成功地在生产应用程序中使用了EF 3.5。在我看来，它几乎没有什么问题，而且这些问题都很小。 - John Saunders

Answer 2

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

• NHibernate
• LLBLGen
• iBATIS

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

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

顺便说一下，良好系统设计的一个通用原则是单一职责原则。在构建系统时，您必须决定是否将不同的职责合并到一个类中。合并职责通常会使系统复杂化，并创建难以解决的设计冲突。

- LBushkin

---

感谢您为那个冗长的描述提供了一个名称 :). 您认为您所描述的映射模型类型是否适合在产品生命周期后期引入（就像我的情况），还是更适合从头开始开发？ - MrEdmundo

这要看情况。有些库更适合使用POCOs，而有些则不是。那些需要消费者实现大量接口或继承特定基类的库显然更难在项目后期引入。例如，NHibernate相对较好地处理POCOs - 因此即使在项目后期，您也可能能够使用它。但是，请记住 - 一致的实现方式是有价值的。在应用程序中有多种不同的数据持久化方式可能不利于长期维护或开发人员入门。 - LBushkin

Answer 3

我经常使用的一种模式是：

• 数据传输对象（DTO）- 这将使数据集使用的内存尽可能小。
• 业务对象 - 至少需要以上DTO作为构造函数 - 这将执行任何不是CRUD功能的DTO上的功能
• CRUD / 持久化方法在Repository类中

后者可以通过以下两种方式之一完成。您可以拥有一个大型存储库类，这对于仅具有少量对象的应用程序/组件来说是可以接受的，或者您可以为每个对象拥有单独的存储库。

请查看Rudy Lacovara的博客。他最近发布了一系列关于使用类似模式的有效数据访问的文章。

- Jason Summers

Answer 4

将存储库与模型分开是一种常见的模式。IO 的名称对于这种模式是独特而有效的。现在，根据你和谁交谈（例如 TDD 狂热者），你可能会因使用静态类而受到指责。

- ChaosPandion

Answer 5

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

将数据访问函数分开放在它们自己的类中很好（为设计师欢呼三声），但将它们散布在各个地方是不好的。理想情况下，这些函数的源代码应该都在同一个目录或文件中（取决于项目的大小）。如果它们全部在一起，您将获得许多优势。将它们分散到（随机？）许多位置会破坏模块化此代码的目的。

- Hogan