我们的数据库中有其他表属于单个服务,只存储数据供自己使用,即在崩溃和恢复或记录业务信息时可以访问的状态信息.我们有一条规则,任何一个表都不能被多个服务访问：因此多个服务所需的数据最终会在DAS中出现.
事实是,我从来没有真正理解为什么数据访问服务是一个好主意,而不是直接访问表.它似乎更慢,我们的DAS不是事务性的,因为它不能发回数据库更新的POCO图(一次只有一个POCOS),我们也有问题,DAS实际上是另一个需要数据的服务的客户端从它…循环依赖.
为什么要打扰DAS？为什么DAS在SOA方面如此重要？我在这里错过了什么？单点控制？
它是一个SOA设计缺陷,并非所有表都是DAS的一部分,而且某些服务有自己的“私有”表吗？
关于这个欢迎的任何讨论.
你是正确的认为这是做事的正确方法,你也是正确的,它减慢了事情,偶尔会很麻烦. SOA必须牺牲一些效率来换取确保与服务相关的所有数据的单一控制点.事实上,在某些SOA圈子里,即使是拥有“通用DAS”服务的想法也有点臭.通过将所有CRUD操作集中到SOA应用程序中的一个服务,您可以确保数据完整性并正确地执行业务规则.举一个例子,想一下你想要存储的实体,它有一些与之相关的业务规则很难从纯SQL角度来看 – 例如,假设一个存储文件引用的表,并创建/更新确保存在这些文件的服务.
使用SOA和这些表的单个访问点,您可以将逻辑编码到创建/更新方法中,并合理地确保您从服务接收的数据是有效的 – 即存在引用的文件.如果有人能够写入这些表或从中检索数据,那么就不存在这样的保证 – 即使你自己调用服务,你也不知道其他程序员,通过恶意或只是计划健忘,忘记实施关键业务规则.这导致了防御性编程,其中每个客户端代码都独立地确保业务逻辑,并最终分散在整个应用程序中的混乱的业务逻辑.
另一个好处是可扩展性和可维护性.假设您的一项服务正在访问大量数据.使用SOA,所有内容都是“黑盒子”,因此您的客户端代码不了解最终如何获取数据.您可以更改您的RDBMS,分区表或实现缓存,并使调用它的客户端代码都不可见 – 确保您只需在一个地方进行痛苦的更新.随着数据库代码分散在整个应用程序中,这种升级变得非常痛苦.