持久化框架？ [英] Persistence framework?

问题描述

我试图决定最佳的策略来访问数据库。我明白，这是一个通用的问题，而且也没有一个很好的答案，但我会提供我正在寻找的一些准则。 我们一直在用我们自己的持久化框架，虽然有限的有服务器，以及过去的一年。然而，它需要一些重大的改进，我想知道我是否应该走那条路，或者使用现有的框架之一。我正在寻找，按重要性排序的标准是：

1. 客户端code应与干净的对象，宽度没有数据库的知识。当使用我们的自定义框架的客户端code是这样的： 是SessionManager会议=新SessionManager（中间）; 订购订购= session.CreateEntity（）; order.Date = DateTime.Now; //设置其他属性 的OrderDetail细节= order.AddOrderDetail（）; detail.Product =产品; //其它性能

   //提交所有更改现在 session.Commit（）;

2. 应该尽可能简单和不灵活。我们需要一种方法来办最多的事。
3. 应具有面向对象编程的良好支持。如果处理一个一对多和多对多一对多的关系时，应处理继承，对延迟加载的支持。
4. 在配置pferred是基于XML的$ P $。

使用我目前的知识我看到这个选项：

1. 在提高我们现有的框架 - 问题是，它需要一个很好的协议的努力
2. 在ADO.NET实体框架 - 还没有很好地理解，但似乎复杂，有坏的评论
。
3. LINQ to SQL的 - 不具有良好的操控性的面向对象的做法
4. NHibernate的 - 似乎是一个不错的选择，但一些用户报告太多陈旧的错误
5. 在亚音速 - 从一个简短的介绍，似乎过于灵活。我不希望出现这种情况。

你会建议？

编辑：

感谢您克雷格的详细的答案。我认为这将有助于更多，如果我给我们的自定义框架的更多细节。我在寻找类似的东西。这就是我们的自定义框架如下：

1. 这是基于数据集，所以你要做的第一件事是配置 数据集和编写查询您需要在那里。
2. 您创建指定数据集表映射到对象，并在它们之间所有类型的指定协会（支持xml配置文件 协会）。 3.A自定义工具解析XML配置和产生必要的code。 4.Generated类从一个共同的继承 基类。

要与我们的框架兼容的数据库必须满足下列条件：

1. 每个表都应有一列作为主键。
2. 所有表必须具有对所产生的相同数据类型的一主键 客户端。
3. 要处理继承只有单表继承 支持。此外xml文件，几乎总是

FER单的方式来实现的东西。我们现在要支持是什么：

删除从数据集的依赖。 SQL code应自动生成，但该框架不应该产生的模式。我想手动控制的DB模式。 对于继承层次更强大的支持。 使用LINQ可选的集成。 我希望这是更清楚，现在我在寻找什么。

解决方案

  

改进我们现有的框架 - 问题是，它需要一个很好的协议的努力

在你的问题，你没有给一个理由你应该重写功能，这可以从很多其他地方。我建议重塑一个ORM不是用好你的时间，除非你有你在你的问题还没有指定的ORM的独特需求。

  

ADO.NET实体框架

我们在现实世界中使用实体框架，制作软件。复杂？没有更多的所以比其他大多数运筹学和管理学，据我所知，这是说，相当复杂的。的但是，它是相对较新，因此没有比东西少社区的经验和文献像NHibernate的。因此，缺乏文件可能使它显得更加复杂。

实体框架和NHibernate采取完全不同的方法来缩小对象关系鸿沟的问题。我在的这个博客帖子。您应该考虑哪种方法是最有意义的给你。

已经有大量的评论约实体框架，正反两方面的。有的却是有根有据的，和一些似乎是来自人谁正在推动其他解决方案。该有理有据的批评包括：

• 在缺乏POCO支持。这不是一个问题对于某些应用，这是一个问题为他人。 POCO的支持可能会在将来的版本中加入，但今天，最好的实体框架可以提供的是IPOCO。
• 在一个单片映射文件。这不是因为我们是一个大问题，因为我们的元数据是不是在不断变化。

然而，一些批评似乎我错过舍本逐末。也就是说，他们谈论的功能比的对象关系映射的基本功能，而实体框架已经证明我们做的非常好等。

  

LINQ to SQL的 - 不具有良好的操控性的面向对象的做法

我同意。我也不喜欢在SQL Server的焦点。

  

NHibernate的 - 似乎是一个不错的选择，但一些用户报告太多陈旧的错误

。

嗯，差不多NHibernate的的好处是，在它周围有一个非常活跃的社区，当你遇到那些深奥的错误（相信我，实体框架也有其份额深奥的错误，它仿佛带境内），你经常可以找到的解决方案变得非常容易。话虽如此，我没有很多个人的经验与NHibernate超出了评估，我们做了这导致我们选择实体框架，所以我打算让其他人有更多这方面的直接经验的评论。

  

亚音速 - 从一个简短的介绍，似乎过于灵活。我不希望出现这种情况。

亚音速是，当然，不只是一个ORM得多，并且亚音速用户有选择不同的ORM实现，而不是使用亚音速的的ActiveRecord的选项。作为一个Web应用程序框架，我会考虑。然而，它的ORM功能不是其存在的理由，我认为这是合理的怀疑亚音速的ORM的部分将得到较少的关注比专用ORM框架做的。

I'm trying to decide on the best strategy for accessing the database. I understand that this is a generic question and there's no a single good answer, but I will provide some guidelines on what I'm looking for. The last year we have been using our own persistence framework, that although limited has server as well. However it needs some major improvements and I'm wondering if I should go that way or use one of the existing frameworks. The criteria that I'm looking for, in order of importance are:

1. Client code should work with clean objects, width no database knowledge. When using our custom framework the client code looks like: SessionManager session = new SessionManager(); Order order = session.CreateEntity(); order.Date = DateTime.Now; // Set other properties OrderDetail detail = order.AddOrderDetail(); detail.Product = product; // Other properties

   // Commit all changes now session.Commit();

2. Should as simple as possible and not flexible. We need a single way to do most things.
3. Should have good support for object-oriented programming. Should handle one-to-many and many-to-many relations, should handle inheritance, support for lazy loading.
4. Configuration is preferred to be XML based.

With my current knowledge I see this options:

1. Improve our current framework - Problem is that it needs a good deal of effort
2. ADO.NET Entity Framework - Don't have a good understanding, but seems to complicated and has bad reviews.
3. LINQ to SQL - Does not have good handling of object-oriented practices
4. nHibernate - Seems a good option, but some users report too many archaic errors.
5. SubSonic - From a short introduction, it seems too flexible. I do not want that.

What will you suggest?

EDIT:

Thank you Craig for the elaborate answer. I think it will help more if I give more details about our custom framework. I'm looking for something similar. This is how our custom framework works:

1. It is based on DataSets, so the first thing you do is configure the DataSets and write queries you need there.
2. You create a xml configuration file that specify how DataSet tables map to object and also specify associations between them (support for all types of associations). 3.A custom tool parse the xml configuration and generate the necessary code. 4.Generated classes inherit from a common base class.

To be compatible with our framework the database must meet these criteria:

1. Each table should have a single column as primary key.
2. All tables must have a primary key of the same data type generated on the client.
3. To handle inheritance only single table inheritance is supported. Also the xml file, almost always of

fer a single way to achieve something. What we want to support now is:

Remove the dependency from DataSets. SQL code should be generated automatically but the framework should NOT generate the schema. I want to manually control the DB schema. More robust support for inheritance hierarchies. Optional integration with LINQ. I hope it is clearer now what I'm looking for.

解决方案

Improve our current framework - Problem is that it needs a good deal of effort

In your question, you have not given a reason why you should rewrite functionality which is available from so many other places. I would suggest that reinventing an ORM is not a good use of your time, unless you have unique needs for the ORM which you have not specified in your question.

ADO.NET Entity Framework

We are using the Entity Framework in the real world, production software. Complicated? No more so than most other ORMs as far as I can tell, which is to say, "fairly complicated." However, it is relatively new, and as such there is less community experience and documentation than something like NHibernate. So the lack of documentation may well make it seem more complicated.

The Entity Framework and NHibernate take distinctly different approaches to the problem of bridging the object-relational divide. I've written about that in a good bit more detail in this blog post. You should consider which approach makes the most sense to you.

There has been a great deal of commentary about the Entity Framework, both positive and negative. Some of it is well-founded, and some of the seems to come from people who are pushing other solutions. The well-founded criticisms include

• Lack of POCO support. This is not an issue for some applications, it is an issue for others. POCO support will likely be added in a future release, but today, the best the Entity Framework can offer is IPOCO.
• A monolithic mapping file. This hasn't been a big issue for us, since our metadata is not in constant flux.

However, some of the criticisms seem to me to miss the forest for the trees. That is, they talk about features other than the essential functionality of object relational mapping, which the Entity Framework has proven to us to do very well.

LINQ to SQL - Does not have good handling of object-oriented practices

I agree. I also don't like the SQL Server focus.

nHibernate - Seems a good option, but some users report too many archaic errors.

Well, the nice thing about NHibernate is that there is a very vibrant community around it, and when you do encounter those esoteric errors (and believe me, the Entity Framework also has its share of esoteric errors; it seems to come with the territory) you can often find solutions very easily. That said, I don't have a lot of personal experience with NHibernate beyond the evaluation we did which led to us choosing the Entity Framework, so I'm going to let other people with more direct experience comment on this.

SubSonic - From a short introduction, it seems too flexible. I do not want that.

SubSonic is, of course, much more than just an ORM, and SubSonic users have the option of choosing a different ORM implementation instead of using SubSonic's ActiveRecord. As a web application framework, I would consider it. However, its ORM feature is not its raison d'être, and I think it's reasonable to suspect that the ORM portion of SubSonic will get less attention than the dedicated ORM frameworks do.

这篇关于持久化框架？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！