c# - 跟踪领域模型变化的良好设计

Question

我们有 2 个独立的现有应用程序，它们只能通过总线消息系统和数据库进行通信。现在我们想通知第二个应用程序在数据库更新之前或之后对第一个应用程序中的域模型所做的任何更改:一旦我们知道有真正的更改要保存在存储中或刚刚保存，我们要​​发送特定消息到一个单独的应用程序。消息未指明进行了何种更改。

一些注意事项:

• 我们想让我们的领域模型变薄，我的意思是内部没有特定的业务逻辑，同时我们不想向我们的数据层(存储库类列表)添加服务引用
• 理想情况下，即使调用了存储库的 Update 方法，如果数据库没有真正的变化，我们也不想发送消息。
• 如果在数据提交到数据库之前发送消息也没关系，即使它们最终被拒绝
• 我们的领域模型由具有数十个属性的数十个对象组成，因此将 OnPropertyChanged 添加到每个属性将花费大量时间
• 我们绝对不想在存储级别上实现通知系统
• 我们希望以任何开发人员都无法绕过此通知机制的方式构建我们的应用程序

在应用程序设计方面，您会推荐我们在案例中使用哪些方法？数据层通过总线系统提交此类通知是好的做法吗？我们怎么知道数据实际上发生了变化:我们可以通过 NHiberate session 知道它还是我们必须跟踪域模型内部的变化？

Answer 1

Is it good practice for Data Layer to submit such notifications via bus system?

不，不是。虽然有些框架开箱即用地支持这一点，但你自己拥有或编写通常是错误的。这里的问题有两个 -

1. YAGNI - 当您预先设计一个系统时，您往往会用高估的机制来淹没它，这反过来会影响系统的效率和简单性。
2. 上下文是关键!拥有一个在没有上下文的情况下通知它所做的一切的存储库太笼统了。考虑在您向表中插入一行以使 UI 更改时发出通知，现在考虑从云端同步数据。将数据批量添加到数据库与您的 UI 刷新率之间存在很强的耦合性，这显然是两件不同的事情。解决这个问题并保持一致性成为一种拖累。

How could we know data were actually changed: can we know it through NHiberate session or we got to track changes inside domain model?

您对要求和这个问题的陈述有些不一致。你这样介绍它 - “如果消息在数据提交到数据库之前发送就没关系，即使它们最终被拒绝了” 然后你说知道数据实际被更改是相关的还是不是。

无论如何，如果您将数据直接保存到数据库中，它通常会返回一些指示，例如修改的行数。使用 NHibernate 等 ORM 框架时，您通常可以立即提交事务并获得相同的指示。

在这两种方式中，如果其他应用程序正在从同一个数据库中检索数据，您应该只让其他应用程序知道数据在数据库中实际发生更改的时间。

What approaches would you recommend us to use in the case in terms of application design?

我们通过将事件发布为逻辑过程的一部分而不是持久性的一部分来解决这个问题，因为您可能有一些不需要通知的操作。如果您仍想在数据方面执行此操作，我不建议在您的存储库中对其进行硬编码，而是使用 Martin fowler 的 Unit of work或 Transaction script模式。它们将允许您决定哪些数据交易应该发布事件，哪些不应该发布事件，以及何时发布。