WCF SOA : CRUD Data Access Service. ..为什么要麻烦(或者我们的设计错误)？

Question

我们的 SOA WCF 系统中有一个数据访问服务。该服务负责对“系统范围”的数据库表执行 CRUD(创建、更新、删除)操作，同时也是查询数据的来源。系统中的任何其他服务想要访问 DAS 控制下的表都必须到 DAS 获取或修改它。我们使用 Entity Framework 并为此 DAS 构建了我们自己的 POCO 状态跟踪系统。

我们的数据库中还有其他表属于单个服务，并且存储数据仅供自己使用，即当它们崩溃和恢复或记录业务信息时它们可以访问的状态信息。我们有一条规则，任何一张表都不能被多个服务访问:因此多个服务所需的数据最终会存储在 DAS 中。

事实是我从来没有真正理解为什么数据访问服务是一个好主意，而不是直接访问表。它似乎更慢，我们的 DAS 不是事务性的，因为它无法发回用于数据库更新的 POCO 图(一次只有一个 POCOS)，而且我们还遇到问题，DAS 实际上是另一个需要数据的服务的客户端从它...循环依赖。

为什么要打扰DAS？对于 SOA，为什么 DAS 如此重要？我在这里想念什么？单点控制？

并非所有表都是 DAS 的一部分并且某些服务有自己的“私有(private)”表，这也是 SOA 设计缺陷吗？

欢迎对此进行任何讨论。

Answer 1

您认为这是做事的正确方法是正确的，而且您也正确地认为它会减慢速度并且有时会很麻烦。 SOA 必然会牺牲一些效率来换取确保与服务相关的所有数据的单一控制点。事实上，即使是拥有“通用 DAS”服务的想法在一些 SOA 圈子里也有点臭。

通过将所有 CRUD 操作集中到 SOA 应用程序中的一项服务，您可以确保数据完整性以及正确执行业务规则。举个例子，考虑一个你想存储的实体，它有一些与之相关的业务规则，从纯 SQL 的角度来看很难接近 - 例如，假设一个存储文件引用的表，并创建/更新确保这些文件存在的服务。

使用 SOA 和对这些表的单一访问点，您可以将逻辑编码到创建/更新方法中，并合理地确保您从服务接收的数据是有效的 - 即引用的文件存在。如果有人能够写入这些表或从中检索数据，则不存在这样的保证 - 即使您自己调用服务，您也不知道其他程序员出于恶意或只是计划健忘而忘记实现关键的业务规则。这导致了防御性编程，其中每一位客户端代码都独立地确保业务逻辑，最终导致散布在整个应用程序中的业务逻辑错综复杂。

另一个好处是可扩展性和可维护性。假设您的一项服务正在访问大量数据。使用 SOA，一切都是“黑盒”的，因此您的客户端代码对最终如何获取数据没有太多了解。您可以更改您的 RDBMS、分区表或实现缓存，并使调用它的客户端代码对所有这些都不可见 - 确保您只需在一个地方进行痛苦的更新。由于数据库代码分散在您的应用程序中，这种升级变得非常痛苦。