blocks|key|793319|text|LLBLGen+Pro在实体内部具有更改跟踪功能。这意味着您可以使用预取路径(即每个图形节点一个查询)从数据库中获取一个图形，并通过线路将其序列化到客户端，在那里更改它，将其发送回去，然后直接保存该图形，因为所有更改跟踪都在实体内(并且在XML中作为紧凑的自定义元素进行序列化)。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|793320|免责声明:我是llblgen+pro的首席开发者。|793321|entityMap|0|LINK|mutability|MUTABLE|url|http://www.llblgen.com/^0|0|B|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

<a href="http://www.llblgen.com" rel="nofollow noreferrer">LLBLGen Pro</a> has change tracking inside the entities. This means that you can fetch a graph from the database using prefetch paths (so one query per graph node) and serialize it over the wire to the client, change it there, send it back and directly save the graph as all change tracking is inside the entities (and is serialized inside the XML as compact custom elements). 

Disclaimer: I'm the lead developer of llblgen pro.

blocks|key|399096|text|这取决于你所说的“SOA”是什么意思。在服务契约中公开领域对象很少是好的服务设计--它公开了内部实现细节，对已发布的契约进行更改的可能性更大，而且版本控制变得非常困难。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|399097|如果您为您的服务端点创建自定义消息文档(例如WCF+)，则使用DataContracts实现服务相对容易。通常，您将从数据库重新加载域对象并映射更改的属性(或调用方法)，然后持久化更改。|399098|如果您的服务主要是CRUD方法，那么您的自定义消息实际上就是DTO。您将需要手动管理开放式并发和域对象映射。|399099|更新：这是一个旧的答案，所以我想指出EF4现在也是includes+change+tracking+in+entities。我仍然认为这是一个糟糕的服务契约设计，但如果您只是想要一个分布式应用程序框架，这可能是一个不错的选择。|offset|length|style|BOLD|399100|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.microsoft.com/en-us/archive/blogs/efdesign/self-tracking-entities-in-the-entity-framework^0|0|0|0|0|3|P|10|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|U|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|V|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|W|8|@$H|X|I|Y|J|K]]|9|@$H|Z|I|10|1|11]]|A|$]]|$1|L|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|M|$N|$5|O|P|Q|A|$R|S]]]]

It depends what you mean by 'SOA'. Exposing domain objects in service contracts is rarely good service design - it exposes internal implementation details, there's a greater likelihood of change to a published contract, and versioning becomes very difficult.
If you create custom message documents (eg WCF DataContracts) for your service endpoints, it's relatively easy to use ORM to implement the service. Typically you would reload the domain object from the database and map changed properties (or call a method), then persist the changes.
If your service is mostly CRUD methods, your custom message will effectively be a DTO. You will need to manually manage optimistic concurrency and domain object mapping.
Update: This is an old answer, so I'd like to point out that EF4 also now <a href="https://docs.microsoft.com/en-us/archive/blogs/efdesign/self-tracking-entities-in-the-entity-framework" rel="nofollow noreferrer">includes change tracking in entities</a>. I still maintain this is poor service contract design, but if you're just after a distributed application framework, it's probably a good option.

blocks|key|399173|text|看一下DataObjects.Net中对upcoming+synchronization+and+disconnected+sets的描述|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|399174|entityMap|0|LINK|mutability|MUTABLE|url|http://blog.dataobjects.net/2009/06/disconnected-offline-entities-poco-and.html^0|K|1A|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Take a look at the description of <a href="http://blog.dataobjects.net/2009/06/disconnected-offline-entities-poco-and.html" rel="nofollow noreferrer">upcoming synchronization and disconnected sets</a> in DataObjects.Net

blocks|key|4180334|text|我谦虚地建议您停止尝试使用分布式对象作为架构模式。它就是不像消息传递架构或RESTful风格那样有效。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4180335|如果您不喜欢将数据传入和传出消息的开销，那么我建议您查看REST。然而，并不是像ADO.NET数据服务那样，它只是基于超文本传输协议的分布式对象。|4180336|REST更多的是在服务器上公开一个丑陋的(但机器可读的)+UI，并使用客户端使其看起来更美观。在REST中，客户端上没有域实体的知识，因此您不需要通过网络发送它们。|4180337|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I would humbly suggest that you stop trying to use distributed objects as an architectural pattern. It is just not as effective as either a messaging architecture or a RESTful style. 

If you don't like the overhead of transferring data in and out of messages then I would suggest you look at REST.
However, not REST in the way ADO.NET Data services does it, that is just distributed objects over HTTP.

REST is more about exposing an ugly(but machine readable) UI on the server and using the client to make it look pretty. In REST there is no knowledge of domain entities on the client so you don't need to send them across the wire.

blocks|key|399012|text|只有在与数据库直接对话时，ORM框架才会对您有所帮助。即使在面向服务的体系结构中，ORM也只能在编程最后一层时帮助减少负载。您还需要其他技术--比如WCF+--来处理服务部分。我还不知道是否有人将对象关系管理和服务集成在一起，但是将相同的类注释为实体和DataContract应该是相当直接的。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|399013|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/netframework/aa663324.aspx|1|http://msdn.microsoft.com/en-us/library/ms733127.aspx^0|3I|C|22|3|0|3I|C|1|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]]|D|@$9|S|A|T|1|U]|$9|V|A|W|1|X]]|E|$]]|$1|F|3|-4|5|6|7|Y|8|@]|D|@]|E|$]]]|G|$H|$5|I|J|K|E|$L|M]]|N|$5|I|J|K|E|$L|O]]]]

The ORM framework will help you only when directly talking to the database. Even in service oriented architectures, ORMs can only help to reduce the load when programming that final layer. You'll need other techniques -- like <a href="http://msdn.microsoft.com/en-us/netframework/aa663324.aspx" rel="nofollow noreferrer">WCF</a> -- to handle the service part. I'm not aware of anyone integrating ORM and services yet, but it should be pretty straight forward to annotate the same classes as entities and <a href="http://msdn.microsoft.com/en-us/library/ms733127.aspx" rel="nofollow noreferrer"><code>DataContract</code></a>s.

blocks|key|2714355|text|SignumFramework在实体内部也有跟踪功能。它也有一个完整的Linq提供程序，但只适用于新数据库(它从您的c#实体生成模式，而不是oposite)。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2714356|更改跟踪：http://www.signumframework.com/ChangeTracking.ashx|2714357|免责声明:我是Signum+Framework的首席开发人员:)|2714358|entityMap|0|LINK|mutability|MUTABLE|url|http://www.signumframework.com/|1|http://www.signumframework.com/ChangeTracking.ashx^0|0|F|0|0|5|1E|1|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@$A|S|B|T|1|U]]|C|$]]|$1|D|3|E|5|6|7|V|8|@]|9|@$A|W|B|X|1|Y]]|C|$]]|$1|F|3|G|5|6|7|Z|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|10|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]|P|$5|K|L|M|C|$N|Q]]]]

<a href="http://www.signumframework.com" rel="nofollow noreferrer">SignumFramework</a> has tracking inside of the entities as well. It also has a full Linq provider, but is ment to work with new databases only (it generates the schema from your c# entities, not the oposite). 

Change Tracking: <a href="http://www.signumframework.com/ChangeTracking.ashx" rel="nofollow noreferrer">http://www.signumframework.com/ChangeTracking.ashx</a>

Disclaimer: I'm the lead developer of Signum Framework :)

blocks|key|800396|text|你可以使用memcached作为NHibernate的二级缓存--这就是你所说的“跟踪”吗？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|800397|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

You can use memcached as a second level cache with NHibernate - is that what you meant by 'Keeping track of' ?

From my experience the major ORM frameworks for .NET (<a href="http://nhforge.org" rel="nofollow noreferrer">NHibernate</a>, <a href="http://msdn.microsoft.com/en-us/library/bb425822.aspx" rel="nofollow noreferrer">LinqToSql</a>, <a href="http://msdn.microsoft.com/en-us/library/aa697427%28VS.80%29.aspx" rel="nofollow noreferrer">Entity Framework</a>) work best when they keep track of loaded objects. This works fine for simple client-server applications, but when using three- or more tier architecture with Web Services in a Service Oriented Archtitecture, this is not possible. Eventually, by writing a lot of code to do the tracking yourself it could be done, but isn't ORM supposed to simplify DB access? 

Is the idea to use ORM in service oriented architecture good at all?

ORM and SOA in the .NET world

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

根据我的经验，.NET的主要对象关系管理框架(、、)在跟踪加载的对象时工作得最好。这对于简单的客户端-服务器应用程序工作得很好，但是当在面向服务的体系结构中使用带有Web服务的三层或更多层体系结构时，这是不可能的。最终，通过自己编写大量代码来进行跟踪，可以做到这一点，但是ORM不是应该简化数据库访问吗？在面向服务的架构中使用ORM的想法好吗？

问.NET世界中的ORM和SOA
EN

回答 7

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问.NET世界中的ORM和SOAEN

回答 7

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问.NET世界中的ORM和SOA
EN