Architecture 关于数据库关系的SOA设计原则

如果我要将我当前的成员资格提供者从我的解决方案中解救出来，即作为一个dll，并将其作为一个具有自己数据库的web服务公开，那么我将如何建模与SOA设计相关的关系

比如说

我有一张桌子：

使用者 id、名称、姓氏、用户名、密码、角色

和桌子

产品

id、名称、价格、创建日期、用户id

外键是表用户的userid

如何对关系建模和/或查询数据库

例如，如果我想在查询之前获取今天上传的所有产品：

SELECT u.name, u.lastname, u.username, p.* FROM PRODUCT p INNER JOIN USER u ON p.userid = u.id WHERE createdate = '05/05/2010'

---

既然数据库中没有该表，我将如何执行此查询？

据我所知，您有两个服务，一个是用户服务，另一个是产品服务，当然您不想连接这些服务

我认为您应该使用另一个服务来协调这两个服务，并在该协调服务中，从产品服务收集产品，然后调用用户服务获取用户名

---

如果它破坏了您的性能，您可以“非规范化”您的服务，将名称添加到产品实体或缓存或其他内容中。但我会尽可能避免这种情况。

我会采取完全不同的方法

您经常会发现，当程序员编写内联动态sql时，需要获得数据的只读视图。因此，当您只需要只读访问时，为什么要填充可以返回n行的重型实体bean？如果您正在处理web服务，这一点尤其正确

相反，我采用的方法是使用CRUD数据服务，该服务返回单个实体bean和一组实体bean（比如产品），对于我需要的只读查询，我使用查找服务。它接受一个查找名称，比如'LookupAllProductsUploadedToday'，并将其映射到一个db存储过程（消除可怕的动态sql！），然后将返回的数据集转换为一个查找bean，它基本上是一个键/值对的集合，并从服务发送到应用程序

---

出于安全原因，我非常喜欢存储过程而不是内联sql，因为这样您就只能授予存储过程读取和执行权限，并拒绝访问执行动态sql语句。我开发了各种SOA应用程序，不需要使用这种方法编写任何内联sql。

这些产品位于需要引用服务中用户的其他实体中的应用程序中。用户过去在数据库中使用外键关系，但我将其删除，以便将会员服务分发给其他应用程序。我可以调用产品表，然后对于每一行调用，将userid传递给服务并检索用户，我只是认为这会导致糟糕的性能。