代码之家 › 专栏 › 技术社区 › Dan Vinton

服务导向和对象导向-它们能共存吗?

service-tier soa oop

Dan Vinton · 技术社区 · 16 年前

人们对 Service-Oriented Architecture (SOA)最近在我的公司。每当我试图了解如何使用它时,我总是碰到一个心理障碍。粗鲁地:

面向对象说:“将数据和操作数据(业务流程)的方法放在一起”;
面向服务说:“保持业务流程在服务中,并将数据传递给它”。

以前开发SOA的尝试最终将面向对象的代码转换为数据结构和操作它们的独立过程(服务),这看起来像是倒退了一步。

我的问题是: 哪些模式、架构、策略等允许SOA和OO协同工作?

编辑: 回答说“面向内部的OO,面向系统边界的SOA”是很好和有用的,但这并不是我想要的。

假设你有一个 Account 具有调用的业务操作的对象 Merge 它与另一个帐户结合在一起。典型的OO方法如下:

Account mainAccount = database.loadAccount(mainId);
Account lesserAccount = database.loadAccount(lesserId);

mainAccount.mergeWith(lesserAccount);

mainAccount.save();
lesserAccount.delete();

我看到的SOA等价物如下所示:

Account mainAccount = accountService.loadAccount(mainId);
Account lesserAccount = accountService.loadAccount(lesserId);

accountService.merge(mainAccount, lesserAccount);
// save and delete handled by the service

在OO的情况下,业务逻辑(以及由于ActiveRecord模式而引起的实体意识)被烘焙到 账户 班级。在SOA案例中, 账户 对象实际上只是一个结构,因为所有业务规则都隐藏在服务中。

我可以同时拥有丰富的、功能性的类和可重用的服务吗?

6 回复 | 直到 12 年前

Jesse Pepper 16 年前

我真的认为SOA只对外部接口(一般来说,对公司外部的接口)有用,即使这样,只有在性能并不重要的情况下,才不需要有序地传递消息。

鉴于此,我认为它们可以共存。使用OO原理保持应用程序的工作和通信,并且只有当需要外部接口(到第三方)时,才通过SOA公开它们(这不是必需的,但是一种方法)。

我真的觉得SOA被过度使用,或者至少带有SOA的架构被提议的太频繁了。我真的不知道有什么大系统在内部使用SOA,我怀疑他们能做到。这看起来更像是一个你可能只是用来做混搭或简单的天气预报类型的请求,而不是在上面构建严肃的系统。

Avi 16 年前

我的观点是SOA在宏观层面上是有用的,但是每个服务可能仍然足够大,需要几个内部组件。内部组件可能受益于OO架构。

应该比内部API更仔细地定义SOA API,因为它是一个外部API。在这个级别上传递的数据类型应该尽可能简单,没有内部逻辑。如果存在属于数据类型的逻辑(例如验证),那么最好有一个服务负责在数据类型上运行逻辑。

James Anderson 16 年前

SOA是用于系统或应用程序之间通信的良好体系结构。

每个应用程序定义一个“服务”接口,该接口由它将处理的请求和预期的响应组成。

这里的关键点是定义良好的服务,以及定义良好的接口。就SOA而言,您的服务实际上是如何实现的无关紧要。

因此,您可以自由地使用所有最新和最好的OO Tequniques或任何其他适用于您的方法来实现您的服务。(我曾经看到过一些极端的情况,“服务”是由实际的人在屏幕上输入数据实现的——但所有的东西仍然是文本书SOA!).

Svante 16 年前

我认为这是对物体定向的误解。即使在Java中,方法一般也不属于物体但是他们的班 (即使是这种“成员资格”也不是面向对象的必要条件,但这是一个不同的主题)。类只是对类型的描述,所以这实际上是程序的一部分,而不是数据。

SOA和OO并不相互矛盾。服务可以接受数据,在内部将它们组织成对象,处理它们,最后以所需的任何格式返回。

joel.neely 16 年前

我听詹姆斯戈斯林说,可以在COBOL中实现SOA。

如果你读过艾伦·凯自己对OOP起源的描述,它描述了一堆相互作用的小计算机来执行一些有用的事情。

请考虑以下描述:

你的X应该由Y组成。每个Y都应该负责一个单一的概念,并且应该完全按照其接口来描述。一个Y可以要求另一个Y通过消息交换(根据其指定的接口)做一些事情。

在某些情况下,x可以由z实现,它根据自己的接口对z进行管理。不允许X直接访问另一个X的Z。

我认为以下替代品是可能的:

Term      Programing       Architecture
----    ---------------    ------------
  X         Program           System
  Y         Objects          Services
  Z      Data structure      Database
----    ---------------    ------------
result        OOP              SOA

如果您主要考虑封装、信息隐藏、松耦合和黑盒接口,那么有相当多的相似性。如果你陷入了多态性、继承等的泥潭中,那么你考虑的是编程/实现而不是体系结构,imho。

Andy Dent 16 年前

如果您允许您的服务记住状态,那么可以将它们视为具有可能较慢的调用时间的大型对象。

如果不允许它们保留状态,那么它们就像您所说的——数据上的操作符。

听起来您可能将系统划分为太多的服务。你有书面的,双方同意的标准如何划分?

采用SOA确实不意思是 扔掉你所有的东西 但它是关于将您的系统划分成可重用的大块。