跟踪复杂对象图中的更改

Question

我开始考虑跟踪断开连接的应用程序中复杂对象图的变化.我已经找到了几个解决方案,但我想知道您是否有最佳实践或使用什么解决方案,为什么？我把同样的问题传递给了MSDN论坛,但我只收到了一个答案.我想从其他开发人员的经验中学到更多答案.

这个问题与.NET有关,所以对于实现细节的答案,我更喜欢与.NET世界相关的答案,但我认为在其他平台上也是如此.

我的案例中的理论问题是在多层架构中定义的(目前不一定是n层),如下所示:

• 使用ORM处理持久性的存储库层(ORM工具目前无关紧要,但很可能是Entity Framework 4.0或NHibernate).
• 表示域对象的纯类(持久无知= POCO,相当于Java世界中的POJO)的集合.存储库保留这些类并将它们作为查询结果返回.
• 使用域实体的域服务集.
• Facade层定义业务逻辑的网关.在内部,它使用存储库,域服务和域对象.域对象未公开 - 每个Facade方法都使用一组专用的数据传输对象作为参数和返回值.每个Facade方法都有责任将域实体转换为DTO,反之亦然.
• 使用外观层和DTO的现代Web应用程序 - 我称之为断开连接的应用程序.通常,设计将来可能会发生变化,因此Facade层将被Web服务层包装,Web应用程序将使用该服务=>过渡到3层(Web,业务逻辑,数据库).

现在假设其中一个域对象是具有订单详细信息(行)和相关订单的订单.当客户请求订购时,它可以修改订单,添加,删除或修改任何订单明细,以及添加或删除相关订单.所有这些修改都是在Web浏览器中的数据上完成的 - javascript和AJAX.因此,当客户端按下保存按钮时,所有更改都会在单个镜头中提交.问题是如何处理这些变化？存储库和ORM工具需要知道修改,插入或删除了哪些实体和关系.我以两个"最佳"解决方案结束:

1. 将DTO的初始状态存储在隐藏字段中(更糟糕的是会话).当接收保存更改的请求时,基于接收的数据创建新的DTO,并基于持久的数据创建第二个DTO.合并这两个并跟踪更改.将合并的DTO发送到外观层,并使用收到的有关更改的信息来正确设置实体图.这需要在域对象中进行一些手动更改跟踪,以便可以从头开始设置更改信息,然后将其传递到存储库 - 这是我不太满意的一点.

2. 根本不跟踪DTO中的更改.当在Facade层中接收修改后的数据时,创建修改后的实体并从存储库加载实际状态(通常是对数据库的附加查询 - 这是我不太满意的一点) - 合并这两个实体并自动跟踪ORM工具提供的实体代理的更改(实体框架4.0和NHibernate允许这样).并发处理需要特别小心,因为实际状态不必是初始状态.

你觉得怎么样？您有什么推荐的吗？

我知道通过在某些应用程序层上使用缓存可以避免一些这些挑战,但这是我目前不想使用的.

我对这个话题的兴趣甚至更进一步.例如,假设应用程序进入3层体系结构,而客户端(Web应用程序)将不会用.NET编写= DTO类无法重用.跟踪DTO的变化将要困难得多,因为它需要其他开发团队在其开发工具中正确实现跟踪机制.

我相信这些问题必须在很多应用中解决,请分享你的经验.

Answer 1

这一切都与责任有关。

（我不确定这是否是您想要的答案 - 如果不是，请告诉我，以便我可以更新）。

因此，我们在系统中有多个层 - 每个层负责不同的任务：数据访问、UI、业务逻辑等。当我们以这种方式构建系统时，我们（除其他外）试图通过使未来的更改变得容易每个组件负责一项任务 - 因此它可以专注于该一项任务并做好它。随着时间的推移和需要进行更改，它还使得修改系统变得更加容易。

在考虑 DTO 时，需要牢记类似的想法——“如何跟踪变化？” 例如。我的做法是这样的：BL 负责管理规则和逻辑；考虑到网络的无状态性质（这是我大部分工作的地方），我只是不跟踪对象的状态并明确地寻找变化。如果用户正在传回数据（要保存/更新），我将传回全部数据，而不关心发生了什么更改。

一方面，这似乎效率低下，但由于数据量并不大，这不是问题；另一方面，“移动部件”更少，出错的可能性也更少，因为过程要简单得多。

我如何将数据传回？-

• 我使用 DTO（或者 POCO 可能更准确）；当我在 BL 和 DAL 之间交换数据（通过接口/ DI）时，数据作为 DTO （或它们的集合）进行交换。具体来说，我对单个实例使用一个结构，对多个实例使用这些结构的集合。

• DTO 是在一个具有很少依赖性的公共类中定义的。

• 我故意尝试限制为特定对象（例如“订单”）创建的 DTO 数量 - 但同时，如果有充分的理由，我会创建新的 DTO。通常我会有一个“胖”DTO，其中包含该对象的大部分/所有可用数据，我也可能有一个更精简的 DTO，旨在用于集合（用于列表等）。在这两种情况下，这些 DTO 都是用于返回“读取”信息的 pureyl。你必须记住责任——当 BL 请求数据时，它通常不会同时尝试写回数据；因此，DTO 是“只读”的事实更多的是为了符合干净的接口和架构，而不是业务规则。

• 我总是为插入和更新定义单独的 DTO - 即使它们共享完全相同的字段。这样，可能发生的最糟糕的情况就是重复一些琐碎的代码——而不是需要理清依赖关系和多个重用案例。

最后 - 不要混淆 DAL 的工作方式和 UI 的工作方式；让 ORM 做他们的事情，仅仅因为他们以给定的方式存储数据并不意味着这是唯一的方式。

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

管理变更是 BL 的工作；让 UI 以最适合用户的方式工作，让 BL 弄清楚它想要如何处理该问题，而 DAL（通过与DI的漂亮干净的界面）只是按照它的指示去做。