.NET 对象持久化选项
我有一个问题，我只是觉得我没有找到满意的答案，要么是我没有找到正确的地方。
我们的系统最初是使用 .NET 1.1 构建的（但是现在所有项目都支持 3.5），所有实体都使用存储过程和具有标准 ExecuteReader、ExecutreNonQuery 类型方法的“SQLHelper”持久保存到数据库中。
因此，通常会发生的情况是，我们将拥有我们的实体，例如 User 和 Role，我们将有另一个名为 UserIO 的类，它使用以下方法将这些对象持久保存到数据库：
static UserIO.SaveUser(User user)
单独 IO 文件的原因是使 IO 与然而，仅仅打电话不是更令人满意吗？：
User.Save()
也许我错了，但让这些“IO”文件散布在各处感觉不太对。所以我正在考虑寻找其他持久性的选择，我想知道从哪里开始是最好的。我过去曾使用过数据集，但有一些复杂的经验，特别是它们的性能。我知道 LINQ 现在已经存在，但我听说我应该使用 ADO.NET 实体框架而不是 LINQ，但后来有人告诉我实体框架不太正确，我应该等待 C# 4.0。如果是这种情况，并且 C# 4.0 即将到来，我应该继续使用“IO”文件方法，并在 C# 4.0 最终发布时从实体框架开始。或者我可以使用更优雅的类结构，例如利用部分类？
我应该说，我并不是考虑完全替换已经存在的数据访问，我更关心我正在创建的新实体。
如果这个问题有点笼统，我很抱歉，但是我周围没有很多人可以反驳这种想法。
I have a question that I just don't feel like I've found a satisfactory answer for, either that or I've not been looking in the right place.
Our system was originally built using .NET 1.1 (however the projects all now support 3.5) and all entities are persisted to the database using stored procedures and a "SQLHelper" that has the standard ExecuteReader, ExecutreNonQuery type methods.
So what generally happens is we'll have our entities for example, User and Role and we'll have another class called UserIO that persists those objects to database with methods like:
static UserIO.SaveUser(User user)
The reason for the separate IO file is to keep the IO separate from the entity however isn't it more satisfactory to just to call?:
User.Save()
Maybe I'm wrong but it just doesn't feel right to have these "IO" files scattered all over the place. So I'm thinking about looking at other options for persistence and I wondered where would be best place to start. I have used datasets in the past but had some mixed experiences particularly with their performance. I know LINQ is around now but I heard that rather than LINQ I should be using the ADO.NET Entity Framework but then somebody else told me the Entity Framework isn't quite right and I should be waiting for C# 4.0. If that's the case and with C# 4.0 just around the corner should I just carry on with my "IO" file approach and start with the Entity Framework when C# 4.0 is finally released. Or is there perhaps a more elegant class structure I could using e.g. utilizing Partial Classes?
I should say, I'm not looking at completely replacing the data access that already exists, I'm more concerned with the new entities I'm creating.
I'm sorry if this question is a little general, however I don't have many people around to bounce this kind of thought off.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我已经成功使用Entity Framework 3.5。有些人（我将其称为纯粹主义者）认为实体框架违反了某些规则，因此不应使用。
在我看来，唯一重要的规则是你自己的规则。我建议您开始尝试使用 Entity Framework 3.5，因为您现在已经拥有它了。此外，您（以及几乎其他所有人）都需要尽快开始尝试 .NET 4.0。候选版本是免费提供的，因此没有理由不至少知道有哪些可用的内容。
您可能会发现自己非常喜欢 4.0 中的 EF 更改，以至于想要等待它。您很可能不需要等待，可以像 3.5 中一样继续从 EF 中受益。我已经收到了，我很高兴我没有等待。
I have successfully used Entity Framework 3.5. There are some, who I would characterize as purists, who felt that Entity Framework violated some set of rules, and should not be used.
In my opinion, the only rules that matter are your own. I recommend you begin experimenting with Entity Framework 3.5, since you have it now. Also, as soon as you can, you (and just about everyone else) need to begin experimenting with .NET 4.0. The Release Candidate is available for free, so there's no reason to not at least know what's available.
It's possible that you'll find you like the EF changes in 4.0 so much that you'll want to wait for it. It's just as likely that you won't feel a need to wait, and can go ahead and benefit from EF as it is in 3.5. I have, and I'm very glad I didn't wait.
如果您正在寻找对象关系映射模型，您可以查看：
这里还有一个更长的列表：http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software#.NET
至于如何设计持久性对象模型的一般问题，设计选择取决于系统的复杂性、所需的可扩展性、是否需要支持多个持久性存储（SQLServer、Oracle、文件系统等）等等。您描述的模式看起来像 DataTansferObject (DTO)。这是将持久性逻辑与业务逻辑分离的常见设计。
顺便说一句，良好系统设计的一般原则是单一责任原则。 在构建系统时，您必须决定将不同的职责组合到一个类中是否有意义。组合职责通常会使系统变得复杂并产生难以解决的设计冲突。
If you are looking for object-relational mapping models you can look into:
There's also a longer list here: http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software#.NET
As for the general question of how to design an object model for persistence, much of the design choice depends on the complexity of the system, the extensibility you require, whether you need to support multiple persistence stores (SQLServer, Oracle, file system, etc), and so on. The pattern you describe looks like a DataTansferObject (DTO). It's a common design for separating persistence logic from business logic.
As an aside, a general principle of good system design is the single responsibility principle. When building a system, you have to decide whether it makes sense to combine different responsibilities into a single class. Combining responsibilities can often complicate a system and create design conflicts that are difficult to resolve.
我经常使用的一个模式是：
每个对象都具有以下内容：
后者可以通过两种方式之一完成。您可以拥有一个大的存储库类，这对于只有几个对象的应用程序/组件来说很好，或者您可以为每个对象拥有单独的存储库。
看看鲁迪·拉科瓦拉斯博客。他最近发表了一系列关于使用类似模式进行高效数据访问的文章。
A pattern that I use quite regularly is:
Each object has the following:
The latter can be done either of 2 ways. You can have a big repository class, which is fine for applications / components with only a few objects, or you can have separate repositories for each object.
Take a look at Rudy Lacovaras Blog. He's recently done a series of posts on efficient data access using a similar pattern.
拥有与模型分离的存储库是一种常见的模式。名称 IO 对于此类模式来说是唯一的，但有效。现在，取决于您与谁交谈（我想到了 TDD 坚果），您可能会因为使用静态类而受到批评。
It is a common pattern to have a repository that is separate from the model. The name IO is unique for such a pattern but valid. Now depending on who you talk to (TDD nuts come to mind) you may get flack for using a static class.
拥有一组实现数据功能的类通常称为分层编程。 （http://en.wikipedia.org/wiki/N-tier）。通过分离访问数据层的类，您可以创建一个更易于维护的系统。如果将这些函数合并到在应用程序中实现业务规则的类中，您将失去多层设计的许多优势。
将数据访问函数放入自己的类中是件好事（为设计者欢呼 3 声），但是让它们散布在各处就不好了。理想情况下，您不会将这些函数的源全部放在同一目录或文件中（取决于项目大小）。如果它们在一起，您将获得许多优势。将它们分成（随机？）许多位置违背了模块化此代码的目的。
Having a set of classes that implement the data functions is often called tiered programming. (http://en.wikipedia.org/wiki/N-tier). By separating out the classes that access the data tier you create a system which is much more maintainable. If you merged those functions into the classes which implement the business rules in your application you would lose many of the advantages of having a multi-tiered design.
Having the data access functions spit into their own classes is good (3 cheers for the designer), however having them spread all over the place is bad. Ideally you would not the source for those functions to all be in the same directory or file (depending on the project size). If they are all together you gain many advantages. Having them split off into (random?) many locations defeats the purpose of modularizing this code.