SOA和共享数据库

我不了解SOA(面向服务的体系结构)和数据库.虽然我被SOA概念所吸引(将可重用的业务逻辑封装到服务中),但我无法弄清楚如果其他服务/系统需要封装在服务中的数据表,它应该如何工作 - 或者SOA适用于所有在这种情况下？

更具体地说,假设我有两个服务:

CustomerService:包含我的Customers数据库表和关联的业务逻辑.

OrderService:包含我的Orders表和逻辑.

现在如果我需要带有SQL语句JOIN的Customers和Orders表怎么办？如果表包含数百万个条目,如果我必须使用SOAP/XML通过网络发送数据,则会产生不可接受的性能.以及如何执行JOIN？

做了一点研究,我找到了一些建议的解决方案:

使用复制在需要时生成所需数据的本地副本.但是那时没有封装,那么使用SOA有什么意义呢？这在StackOverflow上讨论过,但没有明确的共识.

设置主数据服务,封装所有数据库数据.我猜它会变成怪物大小(每个存储过程基本上有一个API调用)并且需要一直更新.对我而言,这似乎与企业数据总线概念有关.

如果您对此有任何意见,请告诉我.

---

编辑:一年过去了,我对SOA的兴趣减少了,概念的普及也是如此.如今,人们似乎想要专注于RESTful服务.

1> Daniel Pittm..：

---

在这种情况下,"服务"的定义原则之一是它绝对拥有它负责的区域中的数据,以及对该数据的操作.

通过复制或任何其他机制复制数据会使该责任失去作用.您也可以复制业务规则,或者您最终会遇到需要更新其他服务以更改内部规则的情况.

使用单一数据服务只是"不做SOA"; 如果你有一个管理所有数据的地方,你没有独立的服务,你只有一个服务.

相反,我建议使用第三种方法:使用组合将数据放在一起,完全避免数据库级JOIN操作.

不考虑需要在数据库中将这两个值连接在一起,而是考虑如何在边缘将它们组合在一起:

当您为客户呈现HTML页面时,您可以从多个服务提供HTML并在视觉上将它们彼此相邻组合:客户详细信息来自客户服务,订单详细信息来自订单服务.

同样,发票电子邮件:可视化地组合从多个服务提供的数据,而无需数据库内连接.

这有两个好处:一,您不需要加入数据库,甚至需要将数据存储在同一类型的数据库中.现在,每个服务都可以使用最适合其需求的数据存储.

二,您可以更轻松地更改应用程序的外部.如果您有小巧的可组合部件,您可以轻松添加以新方式重新排列部件.

---

@DanielPittman这种方法的一个问题:如果我想搜索一组连接的结果,过滤两个表中的字段,该怎么办？例如:查找所有超过100英镑的订单,来自住在柴郡的客户？使用组合方法,我必须从订购服务中找到超过100英镑的所有订单,并从客户服务中找到来自柴郡的所有客户,然后使用组合服务找到交叉点.与使用数据库JOIN相比,订单和客户的集合将大得多,并且性能将大大降低.

---

@PaulTDavies我现在没有任何具体的书籍推荐,但http://msdn.microsoft.com/en-us/library/ms954587是我的观点来源的可靠摘要.具体来说,请参阅"外部数据"与"内部数据"讨论.