这是三层架构吗？
我们正在评估的应用程序是一个使用 spring 和 spring mvc 与 oracle 数据库构建的 Web 应用程序。
浏览器上的每次点击都会以数据库调用结束。
大部分业务逻辑都在数据库过程中。
- 我如何说服我的管理层这不是一个三层应用程序？
- 我如何说服我的管理层这不是面向服务的架构？
The application we are evaluating is a web application built using spring and spring mvc with oracle database.
Every click on the browser ends in a database call.
Most of the business logic is in database procedures.
- How do I convince my management that this not a three tier application?
- How do I convince my management that this is not a Service Oriented Architecture?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
那么，您有三个层 -
因此从技术上讲，您的管理是正确的，至少对于应用程序中的层数而言。你可以很容易地提出这样的论点：他们没有遵循最佳实践，SQL 是一种用于进行业务验证的可怕语言。
关于你的第二点，不可能判断这是否是一个符合 SOA 的应用程序，尽管我打赌我的第一个出生的应用程序是不是。 SOA 相当复杂，你问 10 个人它是什么，你会得到 15 个答案。但根据您的描述，我认为该系统在可发现性、可组合性、自治性、抽象性和松散耦合方面未通过 SOA 测试。服务合同也取决于您如何看待它。
不过，这里有一个问题要问您：您的组织认为需要 SOA 的目的是什么？
Well, you have three tiers -
So technically your management is correct, at least for the number of tiers in the application. You can easily make the argument that they are not following best practices, SQL is a horrible language to be doing business validations in.
On your second point, its impossible to tell if this is a SOA compliant application, though I bet my first born its not. SOA is pretty complicated, and you ask 10 people what it is you will get 15 answers. But based off your description I would say the system fails the SOA test in the areas of discoverability, composability, autonomy, abstraction, and loose coupling. And depending on how you look at it, service contract as well.
Here's a question for you though, what does your organization think it needs SOA for?
从您提供的信息来看，它并不能说明它是三层还是面向服务。
3层通常指UI层/服务层/数据库层。每个人都有自己的责任。面向服务的体系结构通常意味着您拥有单独的可部署服务来执行系统中的不同功能。您的陈述本身并不能证实或否认任何一个定义。
From information that you provided it does not follow whether it is three tier or service oriented.
3 Tier usually means UI layer/Service Layer/Database layer. Each has it's own responsibilities. Service oriented architecture, often means that you have separate deployable services to perform different functions in the system. Your statements alone don't confirm or deny either definition.
您似乎更多地违反了 MVC 模式，而不是多层模式。在典型的 MVC 应用程序中，业务逻辑属于控制器代码而不是数据库过程。然而，三层应用程序通常只需要具有三层：接口层、业务层和持久层。从技术上讲，他们有这个能力。因此，我认为也许您应该认为他们没有正确遵循 MVC，而且他们充其量只是一个实现不佳的三层应用程序。
您还没有提供足够的详细信息来证明它没有使用面向服务的架构（尽管如果是的话，我会感到惊讶）。 SOA 与构成业务逻辑的逻辑组件如何耦合有关。如果它们是松散耦合的东西，可以上下调整并更换为不同的提供者实现，那么它们将拥有 SOA。如果存在紧密耦合，使得逻辑组件不能轻易地彼此分离而不造成重大破坏，那么它们就不会。
如果他们的大部分业务逻辑驻留在数据库过程中，那么他们可能没有SOA，但你永远不知道。他们的其余业务逻辑可能确实遵循这种模式。
What you seem to have is more of a violation of the MVC pattern than of the multi-tier pattern. In a typical MVC application the business logic belongs in controller code and not database procedures. However, a three-tier application is only generally required to have three tiers, an interface tier, a business tier, and a persistence tier. And technically they have that. So I think maybe you should argue that they haven't followed MVC properly, and that at best they have a poorly implemented three-tier application.
You also haven't provided enough details to prove that it's not using a Service-Oriented Architecture (though if it is, I would be surprised). SOA has to do with how the logical components that comprise the business logic are coupled. If they are loosely coupled things that can be brought up and down and swapped out for different provider implementations then they would have a SOA. If there is tight coupling such that the logical components cannot be easily separated from one another without causing major breakages, then they do not.
If they have most of their business logic residing in database procedures, then they probably do not have a SOA, but you never know. The rest of their business logic may indeed follow this pattern.