在复杂的对象图跟踪更改 [英] Tracking changes in complex object graph

问题描述

我开始思考跟踪断开连接的应用程序的变化在复杂的对象图。我已经发现了几个解决方案，但我想知道是否有任何的最佳做法或你用什么办法解决，为什么？我通过同样的问题<一href="http://social.msdn.microsoft.com/Forums/en-US/architecturegeneral/thread/a4023049-a1ad-41ac-9223-86081c294ecf/">MSDN 但我只得到一个答案论坛。我想有更多的答案，从其他开发商学习经验。

I started to think about tracking changes in complex object graph in disconnected application. I have already found several solutions but I would like to know if there is any best practice or what solution do you use and why? I passed same question to MSDN forum but I received only single answer. I would like to have more answers to learn from experience of other developers.

这个问题涉及到.NET这样的答案与实施细节I $相关的.NET世界p $ PFER的答案，但我认为这是在其他平台上是相同的。

This question is related to .NET so for answers with implementation details I prefer answers related to .NET world but I think this is the same on other platforms.

在我的案件的理论问题，在多层次的体系结构定义的（不一定是n层的时刻），如下所示：

The theoretical problem in my case is defined in multi layered architecture (not necessarily n-tier at the moment) as follows:

• 使用ORM应对持久性存储库层（ORM工具并不重要的时刻，但它很可能是实体框架4.0或NHibernate的）。
• 设置纯类（持续性无知= POCO这是在Java世界中等价的POJO）重新presenting域对象。库仍然存在这些类并将它们返回的查询结果。
• 设置的域名服务，域名实体工作。
• 定义门户业务逻辑门面层。内部，它使用存储库，域名服务和域对象。域对象不暴露 - 每门面方法使用设置的参数和返回值专门数据传输的对象。这是每一个立面的方法来变换域实体DTO，反之亦然责任。
• 在现代的Web应用程序，它使用了立面层和DTO的 - 我称之为断开连接的应用程序。通常的设计可以在未来的改变，使得正面层将由Web服务层和网络应用程序被包装会消耗该服务=>过渡到3层（网络，业务逻辑，数据库）。

现在假设域对象之一，是令它有订单详情（线）和相关的订单。当客户端请求的editation定购可以修改订单，添加，删除或修改任何订单细节，添加或删除相关订单。所有这些修改都在Web浏览器上的数据进行 - JavaScript和Ajax。因此，所有的改变都submited在单发射击，当客户端收到保存按钮。现在的问题是如何处理这些变化？信息库和ORM工具需要知道哪些实体和关系进行了修改，插入或删除。我结束了两个最佳的解决方案：

Now suppose that one of the domain object is Order which has Order details (lines) and related Orders. When the client requests Order for editation it can modify Order, add, remove or modify any Order detail and add or remove related Orders. All these modifications are done on data in the web browser - javascript and AJAX. So all changes are submited in single shot when client pushes the save button. The question is how to handle these changes? Repository and ORM tool need to know which entities and relationships were modified, inserted or deleted. I ended with two "best" solutions:

1. 在隐藏字段（在最坏的情况下，以会话）DT​​O的存储初始状态。当接收到请求保存更改创建新的DTO基于基于持续数据接收到的数据和第二DTO。合并这两个和跟踪更改。发送合并后的DTO到外观层，并利用收到的关于正确设置实体图形变化的信息。这需要一些手动更改域对象追踪，这样的变化信息可以从头开始设置，后来传给库 - 这是一点我不是很满意。

1. Store initial state of DTO in hidden field (in worse case to session). When receiving request to save changes create new DTO based on received data and second DTO based on persisted Data. Merge those two and track changes. Send merged DTO to facade layer and use received information about changes to properly set up entity graph. This requires some manual change tracking in domain object so that change information can be set up from scratch and later on passed to repository - this is the point I am not very happy with.

不跟踪更改的DTO的。当接收外观层修改数据来创建修改的实体和加载实际状态从仓库（一般附加查询数据库 - 这点我不是很高兴） - 合并这两个实体，并自动跟踪由ORM工具所提供的实体代理的变化（实体框架4.0和NHibernate允许这样）。需要特别小心的并发处理，因为实际情况并不一定是初始状态。

Do not track changes in DTO at all. When receiving modified data in facade layer create modified entity and load actual state from repository (generally additional query to database - this is the point I am not very happy with) - merge these two entities and automatically track changes by entity proxy provided by ORM tool (Entity framework 4.0 and NHibernate allow this). Special care is needed for concurrency handling because actual state does not have to be the initial state.

你怎么想的？你有什么建议吗？

What do you think about that? What do you recommend?

我知道其中的一些挑战，可避免使用缓存上的一些应用层但这是我不希望的时刻使用。

I know that some of these challenges can be avoided by using caching on some application layers but that is something I don't want to use at the moment.

我的这个话题的兴趣去甚至futher。例如，假设该应用程序进入3层架构和客户端（web应用程序）将不会被写入.NET = DTO类不能被重用。跟踪的DTO的变化将不是更难，因为它需要其他开发团队正确实施跟踪机制，他们的开发工具。

My interest in this topic goes even futher. For example suppose that application goes to 3-tier architecture and client (web application) will not be written in .NET = DTO classes can't be reused. Tracking changes on DTO will than be much harder because it will require other development team to properly implement tracking mechanism in their development tools.

我相信这些问题在很多应用中要解决的，请分享你的经历。

I believe these problems have to be solved in plenty of applications, please share you experience.

推荐答案

这是关于责任。

（我不知道这是答案的那种你追求 - 让我知道，如果不是这样我就可以更新）。

(I'm not sure if this is the sort of answer you're after - let me know if it's not so I can update it).

因此​​，我们必须在一个系统中的多个层 - 每个负责不同的任务：数据访问，用户界面​​，业务逻辑，等等。当我们的建筑师这样，我们的系统（其中包括）努力使未来的变化简单的通过使每个组件负责一个任务 - 因此它可以专注于一个任务，并把它做好。它也可以更容易地修改系统随着时间的推移而变化neeed

So we have multiple layers in a system - each is responsible for a different task: data access, UI, business logic, etc. When we architect a system in this way we are (amongst other things) trying to make future change easy by making each component responsible for one task - so it can focus on that one task and do it well. It also makes it easier to modify the system as time passes and change is neeed.

类似的想法考虑DTO的时候需要在脑海 - ？如何跟踪更改例如。下面是我如何处理它：在BL负责管理规则和逻辑;鉴于网络的无状态特性（这是我做我的大部分工作），我只是没有跟踪对象的状态，并明确地寻求变化。如果用户将数据传递回（保存/更新），我会通过了一大堆回来，而无需关心什么改变。

Similar thoughts need to be in mind when considering the DTO - "how to track changes?" for example. Here's how I approach it: The BL is responsible for managing rules and logic; given the stateless nature of the web (which is where I do most of my work) I'm just not tracking the state of an object and looking explicitly for changes. If a user is passing data back (to be saved / updated) I'll pass the whole lot back without caring what's been changed.

一，一方面这似乎效率不高，但由于数据量不是巨大的，它只是不是一个问题;在不利的一面，有较少的移动部件不太可能出错的过程要简单得多。

One one hand this might seem inefficient but as the amounts of data aren't vast it's just not an issue; on the flipside, there's less "moving parts" less can go wrong as the process is much simpler.

我如何传回数据？ -

How I pass the data back? -

• 我用DTO的（或者是POCO的会更准确）;当我更换BL和DAL之间的数据（通过接口/ DI ）进行数据交换为DTO（或收集它们）。特别是，我使用的是结构的一个实例以及这些结构的多个集合。

• I use DTO's (or perhaps POCO's would be more accurate); when I exchange data between the BL and DAL (via interfaces / DI) the data is exchanged as a DTO (or collection of them). Specifically, I'm using a struct for a single instance and a collection of these structs for multiple.

的DTO在拥有很少依赖一个共同的类中定义。

The DTO's are defined in a common class that has very few dependencies.

我刻意限制DTO的数量是一个创建特定对象（如订单） - 但在同一时间，我会作出新的，如果有一个很好的理由。通常，我将有一个胖DTO包含大部分/所有可用该对象的数据，我也可能有一个更精简的一个被设计在集合中被使用（列表等）。在这两种情况下，这些DTO的是pureyl用于返回的读书的信息。你必须牢记的责任 - 当BL要求的数据通常并不试图将数据写回的同时，这样一个事实，即DTO是只读更多的是遵循一个干净的界面和架构比业务规则。

I deliberately try to limit the number of DTO's a create for a specific object (like "Order") - but at the same time I'll make new ones if there is a good reason. Typically I'll have a "fat" DTO which contains most / all of the data available for that object, I'll also probably have a much leaner one that's designed to be used in collections (for lists, etc). In both cases these DTO's are pureyl for returning info for "reading". You have to keep the responsibilities in mind - when the BL asks for data it's usually not trying to write data back at the same time; so the fact that the DTO is "read only" is more about conforming to a clean interface and architecture than a business rule.

我总是定义单独的DTO的插入和更新 - 即使它们共享完全相同的领域。通过这种方式，最坏的情况是一些繁琐code复制 - 而不是让依赖关系，并多次重复使用的情况下解开

I always define seperate DTO's for Inserting and Updating - even if they share exactly the same fields. This way the worst that can happen is duplication of some trival code - as opposed to having dependancies and multiple re-use cases to untangle.

最后 - 不要混淆DAL如何与UI怎么做;让ORM的做好自己的事情，只是因为它们存储在一个给定的方式中的数据并不意味着它是唯一的方法。

Finally - don't confuse how the DAL works with how the UI does; Let ORM's do their thing, just because they store the data in a given way doesn't mean it's the only way.

最重要的是指定的层与层之间有意义的接口。

The most important thing is to specify meaningful interfaces between your layers.

管理有什么变化是BL的工作;让的方式，最适合你的用户界面的工作，让BL弄清楚它是如何想要对付的是，和DAL（通过你干净的界面的 DI ）少了点什么它说。

Managing what's changed is the job of the BL; let the UI work in a way that's best for your users and let the BL figure out how it wants to deal with that, and the DAL (via your nice clean interface with DI) just does what it's told.

这篇关于在复杂的对象图跟踪更改的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！