WCF SOA：CRUD 数据访问服务...为什么要麻烦（或者我们的设计是错误的）？
我们的 SOA WCF 系统中有一个数据访问服务。该服务负责对“系统范围”数据库表执行 CRUD（创建、更新、删除）操作，也是查询数据的来源。系统中任何其他服务想要访问DAS控制下的表都必须到DAS获取或修改它。我们使用实体框架并为此 DAS 构建了我们自己的 POCO 状态跟踪系统。
我们的数据库中还有其他表，这些表属于单个服务，并且存储仅供其自身使用的数据，即它们在崩溃和恢复或记录业务信息时可以访问的状态信息。我们有一条规则，任何一张表都不能被多个服务访问：因此多个服务所需的数据最终会出现在 DAS 中。
事实是，我从来没有真正理解为什么数据访问服务是一个好主意，而不是直接访问表。它似乎更慢，我们的 DAS 不是事务性的，因为它无法发回用于数据库更新的 POCO 图（一次只能单个 POCOS），并且我们还存在问题，DAS 实际上是另一个需要数据的服务的客户端来自它...循环依赖。
为什么要费心使用 DAS？为什么 DAS 对于 SOA 如此重要？我在这里缺少什么？单点控制？
并非所有表都是 DAS 的一部分并且某些服务拥有自己的“私有”表，这是否也是 SOA 设计缺陷？
欢迎对此进行任何讨论。
We have a Data Access service in our SOA WCF system. This service is responsible for doing CRUD (create, update, delete) operations on "system wide" database tables, and is also the source of this data for queries. Any other service in the system wanting to access the tables under the contol of the DAS have to go to the DAS to get it or modify it. We use Entity Framework and built our own POCO state tracking system for this DAS.
We have other tables in our database that belong to single services and store data only for their own use, ie state information they can access if they crash and resume or recording of business information. We have a rule any one table cannot be accessed by more than one service: so data needed by multiple services ends up in the DAS.
Truth is I have never really understood why a Data Access Service is a good idea as opposed to just accessing tables directly. It seems to be to be slower, our DAS is not transactional as it cannot send back a POCO graph for database update (only single POCOS at a time) and we have issues also where the DAS is actually a client to another service which needs data from it...circular dependancy.
Why bother with a DAS? Why is a DAS so important when it comes to SOA? What am I missing here? Single point of control?
Is it also an SOA design flaw that not all tables are part of a DAS and that some services have their own "private" tables?
Any discussion about this welcome.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您认为这是正确的做事方式是正确的，而且您也正确地认为它会减慢速度并且有时会很麻烦。 SOA 必然会牺牲一些效率，以换取确保与服务关联的所有数据的单点控制。事实上，即使是拥有“通用 DAS”服务的想法在某些 SOA 圈子里也有点令人厌恶。
通过将所有 CRUD 操作集中到 SOA 应用程序中的一项服务，您可以确保数据完整性以及业务规则得到正确执行。举个例子，想象一个您想要存储的实体，它有一些与之关联的业务规则，这些规则很难从纯 SQL 的角度进行处理 - 例如，假设一个表存储文件引用，并创建/更新确保这些文件存在的服务。
通过 SOA 和对这些表的单个访问点，您可以将逻辑编码到创建/更新方法中，并合理地确保您从服务接收的数据是有效的 - 即引用的文件存在。如果任何人都能够写入这些表或从中检索数据，那么就不存在这样的保证 - 即使您自己调用该服务，您也不知道其他程序员由于恶意或只是计划健忘而忘记实现什么关键的业务规则。这导致了防御性编程，其中每一点客户端代码都独立地确保业务逻辑，并最终导致混乱的业务逻辑分散在整个应用程序中。
另一个好处是可扩展性和可维护性。假设您的一项服务正在访问大量数据。对于 SOA，一切都是“黑匣子”，因此您的客户端代码不太了解数据的最终获取方式。您可以更改 RDBMS、分区表或实现缓存，并使所有这些对调用它的客户端代码不可见 - 确保您只需在一处进行痛苦的更新。由于数据库代码分散在您的应用程序中，这种升级变得非常痛苦。
You're correct in thinking that this is the proper way to do things, and you're also correct that it slows things down and can occasionally be cumbersome. SOA necessarily trades off some efficiency in exchange for ensuring single points of control for all data associated with a service. In fact, even the idea of having a "common DAS" service is slightly smelly in some SOA circles.
By centralizing all CRUD operations to one service in an SOA application, you can ensure data integrity and that business rules are being acted upon properly. To give an example, think of an entity you'd like to store that has some business rules associated with it that are difficult to approach from a pure SQL perspective - for example, let's say a table that stores file references, and create / update services that ensure that these files exist.
With SOA and a single access point to those tables, you can code the logic into the create / update methods and be reasonably assured that the data you're recieving from the service is valid - i.e. the files referenced exist. If anyone was capable of writing to these tables or retrieving data from them, no such assurance would exist - even if you're calling the service yourself, you don't know what other programmers, through malice or just plan forgetfulness, forgot to implement that critical business rule. This leads to defensive programming where every bit of client code is ensuring business logic independently, and ultimately a tangled mess of business logic scattered throughout your application.
Another benefit is scalability and maintanability. Let's say one of your services is accessing a huge chunk of data. With SOA, everything is "black-boxed" so that your client code doesn't have much knowledge of how the data is ultimately obtained. You could change your RDBMS, partition tables, or implement caching, and make that all invisible to the client code calling it - ensuring your painful updates only need to be made in one place. With database code scattered throughout your app, this sort of upgrade becomes extremely painful.