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

时间:2010-06-08 08:31:43

标签: architecture membership soa orm

如果我要将我当前的成员资格提供程序从我的解决方案中解放出来,即作为dll并将其作为带有自己的数据库的Web服务公开,我将如何建模与SOA设计相关的关系。

例如

我有一张桌子:

USER id,name,lastname,username,password,role。

和表

产品

id, name, price, createdate, userid

外键是用户ID到表用户。

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

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

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'

既然我没有数据库中的表,我将如何执行此查询?

2 个答案:

答案 0 :(得分:0)

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

我认为您应该使用其他服务协调这两项服务,并在该业务流程服务中,从产品服务中收集产品,并在调用用户服务的用户名后。

如果它破坏了您的性能,您可以“对服务器进行”非规范化“,将名称添加到产品实体或缓存等等。但我会尽可能避免这种情况。

答案 1 :(得分:0)

我会采取完全不同的方法。

您经常发现,当程序员编写内联动态sql时,它是获取数据的只读视图。因此,为什么要填充繁重的实体bean,当您只需要只读访问时,它可以带回n行?如果您正在处理Web服务,则尤其如此。

相反,我采用的方法是返回单个的CRUD数据服务,实体bean的集合说产品,对于我需要的只读查询,我有一个查找服务。其中查找名称为'LookupAllProductsUploadedToday'并将其映射到db存储过程(消除了对可怕的动态sql的需要!)然后将返回的数据集转换为查找bean,它基本上是键/值对的集合并发送退出应用程序的服务。

出于安全原因,我非常倾向于使用内联sql存储过程,因为您只能为存储过程提供读取和执行权限,并拒绝访问执行动态sql语句。我开发了各种SOA应用程序,并且不需要使用这种方法编写任何内联sql。