在多層體系結構中，我是否可以跳過業務層以實現crud操作？

Question

我們有3個分層的應用程序，其中每個來自服務層的調用都通過數據層進入業務層和peresist。 每層的組件只能調用下面的圖層;

但是，因爲我們有數百個實體，並且我們有很多與crud operatins相關的服務，所以我們團隊中提出了許多內容。

一些人認爲，爲了維護和易於開發，最好從粗劣服務調用數據訪問，這些服務只是在進行粗劣操作並繞過業務層。

相反，有些人說我們必須爲業務層中的每個實體的數據訪問創建包裝，並從服務調用這些包裝，並且絕不允許服務調用數據訪問層。

在你的想法中我們應該採取哪種方式？ crud服務可以調用數據訪問並繞過業務層嗎？

Answer 1

如果沒有業務邏輯可執行，則沒有理由執行業務層。三層體系結構不是一個神祕的協議，只是業務處理過程中形成的最佳實踐。

在當前的應用程序中，我們經常在沒有涉及業務流程的情況下直接從JSF控制器訪問DAO。這個想法是由java champion給出的，他強調了簡單性至關重要的觀點。

如果您擔心未來可能需要添加業務邏輯的修改。我這樣思考問題：無論如何，額外的業務邏輯將被添加到業務層，包括數據訪問，所以這裏沒有區別。

CRUD代碼大多非常簡單。因此，服務中的更改將等於將DAO中的一個調用或幾個調用重新路由到一個EJB - 這是一個簡單的重構。 CRUD代碼本身仍然存在，但會被推入到EJB中 - 另一個簡單的重構。

這並不完美，但IMO更好，然後替代方案：有一個空的間接層。這增加了無用的複雜性。業務對象只會將呼叫轉發給DAO。

有兩個code smells，我認爲適用於這種情況：人爲的複雜性和feature envy。

我不是說業務層中的DA是某種代碼味道。我的意思是有一個沒有別的的業務對象，但代理DAO是一種氣味。這與複雜性相同 - 一個沒有自己的目的的增加的數據結構/架構層 - 似乎應用程序中已經有了DAL。

您考慮的另一方面是 - 開發人員看到直接使用DAO的服務有多令人驚訝？有5個服務，其中2個直接訪問DAO不同於100個服務，其中只有一個服務直接訪問DAO。在第一種情況下，代碼的簡單性將超過增加的概念複雜性（2個概念對於單一事物），在第二種情況下，我寧願堅持業務層 - 驚喜（也稱爲WTF效應; ）以不同的方式做一次就太大了。

Answer 2

如果您只有CRUD操作，則可以使用Data Services將數據集發佈爲Web服務。一個很好的例子是WSO2數據服務http://wso2.com/products/data-services-server/

Answer 3

在我看來，呼叫CRUD服務繞過業務層將開始將當前服務層轉換爲業務層，同時增加功能。所以你的服務層也會充當業務層，如果你沒有問題的話。

在大多數情況下，您處理一個實體，可能涉及到多個數據層crud調用，例如一次更新。爲此推薦業務層。業務層是執行任何業務規則，緩存或調用其他業務服務的地方。這將保持上層簡單並通過。

Answer 4

我不會繞過業務層。即使它看起來像只是將DAL的調用代理到BL中，並且即使這可能是非常簡單的CRUD操作的情況，BL也可以封裝操作所需的驗證邏輯。驗證邏輯可以在BL上執行，並且只有驗證條件滿足時纔會執行代理到DAL。