这是一个三层架构吗?

时间:2011-08-01 06:24:06

标签: java spring java-ee

我们正在评估的应用程序是使用带有oracle数据库的spring和spring mvc构建的Web应用程序。

  

浏览器上的每次点击都以数据库调用结束。

     

大多数业务逻辑都在数据库过程中。

  • 如何让我的管理层相信这不是三层申请?
  • 如何让我的管理层相信这不是面向服务的架构?

3 个答案:

答案 0 :(得分:3)

嗯,你有三层 -

  • 数据库(Oracle 3g)
  • 中间件集成(Spring)
  • UI(Spring MVC)

从技术上讲,您的管理是正确的,至少对于应用程序中的层数是这样。您可以轻松地提出他们没有遵循最佳实践的论点,SQL是一种可怕的语言,可以进行业务验证。

关于你的第二点,我不可能知道这是否是一个符合SOA的应用程序,尽管我打赌我的第一个生日不是。 SOA非常复杂,你问10个人你会得到15个答案。但根据您的描述,我会说系统在可发现性,可组合性,自治性,抽象性和松耦合方面都未通过SOA测试。而且取决于你如何看待它,服务合同也是如此。

以下是一个问题,您的组织认为它需要SOA吗?

答案 1 :(得分:2)

根据您提供的信息,它不会遵循它是三层还是面向服务。

3层通常表示UI层/服务层/数据库层。每个人都有自己的责任。面向服务的体系结构通常意味着您具有单独的可部署服务以在系统中执行不同的功能。你的陈述本身并不能证实或否认这两种定义。

答案 2 :(得分:2)

您似乎拥有的更多是违反MVC模式而不是多层模式。在典型的MVC应用程序中,业务逻辑属于控制器代码而不属于数据库过程。但是,三层应用程序通常只需要有三层,一个接口层,一个业务层和一个持久层。从技术上讲,他们就是这样。所以我想也许你应该争辩说他们没有正确地遵循MVC,而且他们最多只有一个实施不好的三层应用程序。

您还没有提供足够的详细信息来证明它没有使用面向服务的体系结构(尽管如果是这样,我会感到惊讶)。 SOA与构成业务逻辑的逻辑组件如何耦合有关。如果它们是松散耦合的东西,可以上下移动并交换出来用于不同的提供程序实现,那么它们将具有SOA。如果存在紧密耦合使得逻辑组件不能容易地彼此分离而不会导致严重破坏,那么它们不会。

如果他们的大多数业务逻辑都驻留在数据库过程中,那么他们可能没有SOA,但你永远不会知道。其余的业务逻辑可能确实遵循这种模式。