分層架構

Question

我有一個我從來沒有能夠解決一個問題：

考慮這兩種架構

UI layer 
    | 
Application layer 
    | 
Domain Layer 
    | 
Infrastructure Layer 

第二

Client Tiers 
    | 
Presentation Tiers 
    | 
Business Tiers 
    | 
Integration Tiers 
    | 
Resources Tiers 

什麼是他們之間的區別。

實體bean在這些架構中的位置。如果我有一個帶有實現業務邏輯的對象的業務層，爲什麼我必須在實體bean中添加行爲。我在某處讀到，這是一種反模式，讓域模型對象沒有行爲。

感謝

更新

這實際上是一個項目（培訓），我需要做的就是我在分佈式系統中MSC。

這些其實都是我使用

的Struts 2 JPA HSQLDB

所以，如果我的理解以及

我的應用程序由

客戶端層（網絡瀏覽器技術） 表示層（struts 2） 業務層（POJOs + JPA） 集成層（帶有休眠DAO） 資源層（HSQLDB）

但是，作爲演示文稿，業務和集成層是在同一臺服務器上執行的（tomact），我只有三層架構。我對嗎 ？

至於在我的JPA對象中包含行爲，通常這是我以前做的事情： 爲每個JPA實體都有一個dao。 有一個可以管理所需業務邏輯的bean（如EJB）。所以我從不在JPA對象上放置行爲。

說例如我想提出購買請求。我會有一個CatalogueManager，它可以幫助我與物品，供應商進行互動。我也會有一個EmployeeManager，它可以幫助我與員工互動。最後，一個PurchaseRequestManager將使用前兩個業務對象來創建一個PurchaseRequest。

現在你告訴我的是將PurchaseManager中的方法放在PurchaseRequest JPA實體中，並對EmployeeManager =>中的方法執行以將它們放入Employee JPA實體中。

但是如果我的僱員對象也用於人力資源部門會發生什麼，我還需要將其他方法放在那裏。對於大型應用程序，我會在員工JPA實體中使用很多方法。這不會是反效果的嗎？

感謝

Answer 1

在我的腦海裏，「層」是一個合乎邏輯的分離，沒有暗示部署拓撲。

「層」是關於物理部署。例如，UI層邏輯可以完全在胖客戶端中實現，部署到桌面上的客戶端層並且不需要單獨的表示層，或者可以是基於Web 2.0瀏覽器的應用，UI層在UI UI客戶端之間服務器中的瀏覽器和表示層。

現在到Entitiy豆。首先，Entity Beans在EJB 3中被替換爲JPA - 我們註釋對象以控制其持久性。

我認爲你有兩種業務邏輯，即與客戶，訂單，員工，發貨，學生，課程等各個持久性類的行爲有關的業務邏輯，然後是邏輯處於比這個更高的水平，處理這些類的組合。

對我來說，與客戶行爲有關的邏輯應該在客戶類中是合理的。這種行爲可能非常微不足道，例如某些類型的驗證和總結（例如總訂單值），但它是域邏輯，並且可以合理地存在於這些域對象中。所以我們的JPA對象有兩個角色，實現域邏輯並且通過註釋來管理持久性。這些註釋的架構狀態很有趣，它們實際上是域和基礎架構之間的「粘合劑」。

Answer 2

從Wikipedia：

層和層的概念通常可互換地使用。然而，一個相當普遍的觀點是確實存在差異，並且層是構成軟件解決方案的元素的邏輯構造機制，而層是用於系統的物理構建機制基礎設施。

基本上，有3個「零件」，以地址：

1. 客戶 - 這是介紹情況，並在客戶端編程存在（JavaScript）的爲您的應用程序的動態交互。

2. 業務 - 這是所有您的業務邏輯存在的地方。算法，領域模型，您的應用程序的「肉」。如果你使用EJB，EJB就住在這裏。

3. 數據 - 通常是您從業務層訪問的數據庫。

您的（不推薦的）實體bean存在於業務層中。但是不要使用JPA，因爲它更現代，更簡單。

您也可以將JPA實體用於業務邏輯，因爲它們相當「輕量級」，所以不需要完全分離。

爲了簡單起見，不要過度使用「架構」，「設計模式」，「企業模式」或任何聽起來太企業化的東西。