我想要一个ORM吗？

我们有一个在三个应用程序中使用的对象模型。两个程序收集数据，另一个读取数据并生成报告。这个系统非常不连贯，所以我们不能有一个单一的数据库，所有的程序都可以对话。我想要一个ORM吗？

现在，程序只是使用公共库来填充对象模型并序列化/反序列化到磁盘。具体来说，我们正在使用XML序列化。

这个模型有几个问题。 1）XML可能被认为是浪费。这些文件可能变得庞大而笨拙。老实说，文件大小现在不是一个大问题。 2）我最关心的是记忆足迹。整个文件被加载到一个对象模型中，对其进行操作，然后保存。

希望我已经表达了我的担心，在某些时候，我们会在运行时遇到有关此应用程序的内存问题。足够的数据将被收集到一个“数据库”（xml文件），它不能一次加载到内存中。

我想要的是访问我的对象模型支持文件存储而不是内存。我希望对象模型的更改最小化。当一个对象被访问时，它来自磁盘，当它被设置时，它会被保存（如果可能，会自动保存）。

我们用SQLite，SQL Compact 4.0和EF 4以及LINQ to XML（简要地）研究了NHibernate。过去我也使用db4o将对象缓存到磁盘，但那是一个无关的项目。

在我潜入并花时间学习其中之一之前，我想知道我的想法是否有意义。我可以有一个对象模型“神奇地”缓存到存储介质，而不是无限地膨胀我的内存足迹？即使它不是最优雅的，完成这件事的最短路径是什么？

是否有其他技术可以帮助我？内存映射文件，linq-to-sql，Lazy（T）（仅在需要时才从文件中获取对象）。

我意识到这是一个开放式问题。我正在寻找一个大的图片响应和细节，如果有人在那里有真实世界的经验这样做。链接将有帮助...

谢谢。

来源

2011-03-03 Nate

您是否因为使用移动设备而有内存问题？我问，因为我看到sql-server-ce作为标签。 – 2011-03-03 08:08:23

现在不能移动，看着SQL Server Compact，因为它可以嵌入到我的应用程序中（比如SQLite）。如果我们使用EF，SQL Compact将成为数据库后端的考虑因素。内存方面的担忧是由于它是一款32位应用程序，因此2GB的处理限制。 – Nate 2011-03-03 08:12:22

您的应用是独立应用吗？这听起来像你不想要一个集中的数据库。该应用是否为多用户？你多久更新一次？对应用程序做了多少报告？这些是您选择时重要的问题类型。 – Andrew 2011-03-03 08:31:41

我刚刚完成将一个（通常是“继承的”）由XML文件支持的Web应用程序迁移到NHibernate，完全出于同样的考虑。我也处于以前从未使用NHibernate并希望在此过程中学习的相同情况。这个想法确实有道理。你确实能够在内存中加载你实际需要的部分（而不是整个数据库）以及更多的好处。

基于您要求的其他事情（对象模型的最小更改，可轻松从实际迁移到基于ORM的应用程序）我不确定您会如此轻松地获得它们。对于像NHibernate和EF4这样的ORM，模型类非常轻便：它们基本上只比属性容器更多。基于XML文件的应用程序往往直接在模型中使用更多的逻辑：您可能必须转移到数据访问层的逻辑。重新设计模型和数据访问层可能是您将面临的最耗时的任务。我知道这是给我的。

我从你的问题推断出的另一件事（你说你不能让所有的三个程序都与同一个数据库对话，而你提到SQLite和SQL Compact）就是你正在通过复制你的三个应用程序来复制你的数据身体文件。你如何检测到变化以及你需要3个DB如何对齐？您目前如何合并更改（如果您有3个应用程序中的2个可以写入数据）？根据您复制数据的方式，这是ORM可能或不可以帮助您的事情。

编辑根据您的意见

如果你想在一个点上的文件合并到一个数据库和您还不相信这将是微软的产品，然后NHibernate的是一些积分最佳选择。但是，如果您现在正在广泛使用LINQ（根据您的其他评论）并希望进行更加无缝的转换，那么我将使用EF4：Nhibernate.Linq并非真正完整，某些构造不起作用。

NHibernate和EF4都有很好的文档记录，并且有非常好的教程，介绍如何从头开始构建完整的应用程序，因此学习部分非常简单。

两者都有一个“模型第一”的方法，您可以根据您的模型类获得一个为您创建数据库的工具，因此如果您的模型类非常轻量级，则应该可以稍加修改地使用它们。

在NHibernate中花费了我一些时间（并且仍然有时候很难让我工作）的事情是配置级联以符合我的预期：删除对象时“相关”对象会发生什么？

来源

2011-03-03 08:31:16

感谢您分享这些信息。我的对象模型目前非常轻量级。每个对象只是一些属性，其中有一些更改的数据绑定事件...所以EF或NHibernate可能是适当的。我担心学习过程需要多长时间。这两种产品看起来都很复杂。就合并而言，我现在并不担心它。目前，我们一次只能处理一个文件。明年可能会将文件合并到中央数据库中。我们已经努力使对象在文件间唯一标识。 – Nate 2011-03-03 15:54:12

@Nate：而不是在评论中回答我直接编辑我的答案（太长的评论...）。希望能帮助到你。 – 2011-03-04 07:14:30

非常感谢您的额外信息。我正在深入挖掘NH和EF。我发现自己对EF的兴趣不大。设置看起来很复杂。 – Nate 2011-03-05 08:19:38

是的，ORM将一个对象模型映射到关系模型。他们在隐藏读写数据到数据库，缓存数据，管理内存等所有管道工作方面做得非常好。他们还能够缓存对象图的一部分，并且可以做一些事情来提高性能如延迟加载数据。

来源

2011-03-03 07:56:03 Andrew

谢谢，听起来我正走向一条好路。 – Nate 2011-03-03 15:55:02

我的建议是你使用文档数据库。 RavenDB会给你很多好处。您将能够存储这些对象，而无需将它们转换为关系模型，就像db4o会做的那样。

但是，使用RavenDB您可以使用Map/Reduce查询数据。另一个好处是，它是使用.NET for .NET编写的，所以您会喜欢在Linq中查询。它可以作为Windows服务或IIS运行。它也可以运行嵌入式，这对于测试目的非常有用。这对您的数据收集应用程序可能是一个好主意。

RavenDB还支持复制，以便您可以将数据存储在一个实例中并将其复制到另一个实例中。也许这可以解决你的分布式设置。

但是，根据分布式设置的性质，我认为使用服务总线会更好。数据收集应用程序中是否需要状态？如果没有，只需在服务总线上发布一条包含数据的消息，以供系统的另一部分使用。听起来很复杂，但实际上并非如此。看看nServicebus。

来源

2011-03-03 08:50:51

RavenDB听起来很有趣。我喜欢这种格式是JSON。我被db4o的许可模式关闭了。他们想要每个应用程序的合同，成本很高。这似乎更合理。我可能会研究它。至于nServicebus，这听起来也很有趣，也许我们会在明年展望。目前，使用运动鞋的网络复制文件。机器在地理上与任何网络分离并断开连接。明年我可能不得不将某些“上传者”放在一起，以便在机器回到“母舰”时使用。 – Nate 2011-03-03 15:59:55

我想要一个ORM吗？

回答

相关问题