值得在Linq to SQL之上放置業務邏輯層嗎？

Question

我覺得我可能會做些愚蠢的事情。

我已經有一個Linq to SQL庫運行好幾年了，並且在多個使用相同數據庫的應用程序中使用它。雖然我並不滿意，但我還是得到了一個新項目。我認爲在應用程序和Linq to SQL庫之間放置一個業務邏輯層是有幫助的。問題是我設計的越多，看起來就越像我試圖實現的東西，就像Linq to SQL一樣。

例如，我決定應用程序應該有一個業務邏輯入口點。因此，入口點（我稱之爲MCP）具有系統中類的屬性，並且此屬性具有包含來自相應表的所有對象的「列表」（可能是IQueryable）。開始聽起來很像Linq to SQL數據上下文......再加上我覺得在每個現有對象周圍都有一個額外的對象/存取器是一大堆額外的輸入，只是爲了隱藏「真實」的對象。

因此，我有點害怕，我只是做了我已經有的重新實施。

另一方面，我希望改善一切工作方式。例如，確保一個對象具有一個邏輯責任，而不是一種訪問系統中其他任何東西的方式。 （例如一個CarCP可能有一個AddDriver（Person p）的方法，但Person不一定有方法返回到CarCP。）

所以也許最好有這個中間層，但我只是很糟糕的設計？

Answer 1

我花了很多年試圖實現類似的東西。我知道沒有一個程序員對遵循「三層」思想的結果感到滿意。直到我退後一步，看看我在做什麼，我才決定完全放棄這種做法。

首先，沒有人向我展示過一個「業務邏輯」層，我認爲「哦，這實際上相當不錯！」。他們似乎都有問題。我認爲這些可能性與我們相反。其次，任何不增加價值的代碼行都不應該存在，並且這三層的想法似乎需要大量沒有好處並且是純開銷的'包裝'。

最後，如果你退一步一點，認爲它是這樣的：

數據層和業務邏輯層，似乎很容易讓開發人員能夠訪問大量的全局狀態。這真的是我們想要的嗎？我們認爲分享國家是一個好主意嗎？

更重要的是，共享狀態與使用全局變量有相同的缺點嗎？您不僅可以修改數據，還可以在多個應用程序中使用「DAL」，使數據比全局變量更具全局性。

它會導致試圖弄清楚爲什麼應用程序X的最新版本引起了布爾在結束了擰應用Y.

---

我暗示的數據庫行改變的樂趣種種方法只是錯誤的路徑。對不起，這不是一個可以給你即時結果的答案。

我想推薦一些東西。您可以在查找哪些代碼區域訪問相同的數據時將其分組，並將它們組合在同一個庫中。如果你這樣做，你會發現數據訪問，邏輯和用戶界面分組在一起 - 這是三層方法的完全相反。