這是三層架構嗎？

Question

我們正在評估的應用程序是一個使用spring和spring mvc與oracle數據庫構建的Web應用程序。

瀏覽器的每次單擊都以數據庫調用結尾。

大多數業務邏輯都在數據庫過程中。

• 如何使我的管理層確信這不是三層應用程序？
• 如何使我的管理層確信這不是面向服務的體系結構？

Answer 1

好吧，您分為三層-

• 數據庫（Oracle 3g）
• 中間件集成（春季）
• 使用者介面（Spring MVC）

因此，從技術上來說，您的管理是正確的，至少對於應用程序中的層數而言是正確的。 您可以輕松地說出他們沒有遵循最佳實踐，SQL是進行業務驗證的可怕語言。

關於第二點，雖然我敢肯定我的第一個不是SOA兼容應用程序，但無法確定這是否是符合SOA的應用程序。 SOA非常復雜，您問10個人，這是什么，您將獲得15個答案。 但是根據您的描述，我會說系統在可發現性，可組合性，自治性，抽象性和松散耦合方面未能通過SOA測試。 根據您的看法，也可以簽訂服務合同。

不過，這是一個問題，您的組織認為它需要SOA做什么？

Answer 2

從您提供的信息來看，它不是三層的還是面向服務的。

3層通常表示UI層/服務層/數據庫層。 每個人都有自己的責任。 面向服務的體系結構通常意味着您具有單獨的可部署服務，以在系統中執行不同的功能。 僅您的陳述並不能確認或否認任何定義。

Answer 3

您似乎擁有的更多是違反了MVC模式，而不是多層模式。 在典型的MVC應用程序中，業務邏輯屬於控制器代碼，而不屬於數據庫過程。 但是，通常只要求三層應用程序具有三層，即接口層，業務層和持久性層。 從技術上講，他們有。 因此，我認為也許您應該辯稱他們沒有正確遵循MVC，並且充其量來說，他們的三層應用程序實施情況很差。

您還沒有提供足夠的細節來證明它沒有使用面向服務的體系結構（盡管確實如此，我會感到驚訝）。 SOA與構成業務邏輯的邏輯組件如何耦合有關。 如果它們是松散耦合的東西，可以調高或調低，然后換成不同的提供程序實現，則它們將具有SOA。 如果存在緊密的耦合，使得邏輯組件在不引起重大破壞的情況下不容易彼此分離，那么它們就不會。

如果他們的大多數業務邏輯都駐留在數據庫過程中，那么他們可能沒有SOA，但您永遠不會知道。 他們的其余業務邏輯確實可以遵循這種模式。