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