根据我的经验，.NET 的主要 ORM 框架（NHibernate、LinqToSql、Entity Framework）在跟踪加载的对象时效果最好。这适用于简单的客户端-服务器应用程序，但是当在面向服务的架构中使用具有 Web 服务的三层或更多层架构时，这是不可能的。最终，通过编写大量代码自己进行跟踪可以完成，但 ORM 不应该简化数据库访问吗？
在面向服务的架构中使用 ORM 的想法真的好吗？
Rumen Georgiev
问问题
2198 次
7 回答
7
LLBLGen Pro在实体内部具有更改跟踪。这意味着您可以使用预取路径从数据库中获取图形（因此每个图形节点一个查询）并通过线路将其序列化到客户端，在那里进行更改，将其发送回并直接保存图形，因为所有更改跟踪都在里面实体（并在 XML 中序列化为紧凑的自定义元素）。
免责声明：我是 llblgen pro 的首席开发人员。
于 2009-01-05T11:47:48.390 回答
4
这取决于您所说的“SOA”是什么意思。在服务合同中公开域对象很少是好的服务设计——它公开了内部实现细节，更改已发布合同的可能性更大，并且版本控制变得非常困难。
如果您为服务端点创建自定义消息文档（例如 WCF DataContracts），则使用 ORM 来实现服务相对容易。通常，您会从数据库重新加载域对象并映射更改的属性（或调用方法），然后持久化更改。
如果您的服务主要是 CRUD 方法，那么您的自定义消息将有效地成为 DTO。您将需要手动管理乐观并发和域对象映射。
更新：这是一个旧答案，所以我想指出 EF4 现在还包括在实体中的更改跟踪。我仍然认为这是一个糟糕的服务合同设计，但如果你只是追求分布式应用程序框架，它可能是一个不错的选择。
于 2009-01-08T04:05:21.083 回答
3
看一下DataObjects.Net中即将到来的同步和断开集的描述
于 2009-07-03T20:36:41.387 回答
2
我会谦虚地建议您停止尝试将分布式对象用作架构模式。它不如消息传递架构或 RESTful 风格有效。
如果您不喜欢将数据传入和传出消息的开销，那么我建议您查看 REST。但是，REST 不像 ADO.NET 数据服务那样，它只是基于 HTTP 的分布式对象。
REST 更多的是在服务器上暴露一个丑陋的（但机器可读的）UI，并使用客户端使其看起来更漂亮。在 REST 中，客户端上没有域实体的知识，因此您不需要通过网络发送它们。
于 2009-03-11T12:40:26.107 回答
1
ORM 框架只会在直接与数据库对话时为您提供帮助。即使在面向服务的架构中，ORM 也只能在对最后一层进行编程时帮助减少负载。您将需要其他技术（如WCF）来处理服务部分。DataContract我还不知道有人集成了 ORM 和服务，但是注释与实体和s相同的类应该非常简单。
于 2009-01-05T09:46:10.040 回答
0
SignumFramework在实体内部也有跟踪。它还有一个完整的 Linq 提供程序，但只能使用新数据库（它从您的 c# 实体生成模式，而不是相反）。
变更跟踪：http ://www.signumframework.com/ChangeTracking.ashx
免责声明：我是 Signum 框架的首席开发人员 :)
于 2009-03-11T12:24:35.910 回答
0
您可以将 memcached 用作 NHibernate 的二级缓存 - 这就是您所说的“跟踪”的意思吗？
于 2010-07-21T07:39:45.650 回答