您是否嚴格遵循項目中各層之間的n層架構和關注點分離？

Question

我想大多數開發人員都有多層架構的想法。我們有DAL（數據訪問層），我們有BLL（業務邏輯層），並且在我們擁有用戶界面的路的盡頭。如果你有一個項目遵循這些原則，你是否保留（或至少試着）保留/放置他們在概念上屬於的東西？我特別感興趣的是與其他許多人一起工作的大公司應用程序。顯然，你可以用你的私人玩具項目做任何你想做的事情，發明任何一種建築並堅持下去。大型項目中很多人對軟件或整體混亂做出貢獻並不容易。

例如，我碰巧看到像UI組件直接到數據庫的東西，以獲取BL所不提供的一些「缺失的」額外數據，UI和BL都使用低級元素（如表格字段）意見，他們應該將這些操作委託給較低級別​​的DAL。在與高級開發人員討論這些事情後，我看到他根本沒有發現問題，這讓我感到特別難過。

我們當然可以認爲我和誰共享我的觀點的人都是完美主義者，但我清楚地看到了一個非常不利的後果，因爲我花了很長時間在我的一些任務中追蹤所有「平行「數據傳入和傳出數據庫的路線，並確定誰現在可能受到我實施的新功能的影響。就我看到的情況而言，當有人決定儘快破解並儘快完成任務時，這會增加進一步的開發/維護成本，從而超額節省一些存款。

您的項目是「純粹的」還是放棄了很久以前在圖層之間保持清晰界限的想法？如果你仍然保持正確，那麼你如何處理那些不瞭解這些事情的同事，或者不關心他們只是一直在建立「定製」解決方案和黑客入侵？或者在某個時候，你停止與風車戰鬥，並接受它作爲你的懲罰？ 編輯：有點驚訝，沒有多少人對這個問題感興趣。這是最不關心的標誌嗎？

Answer 1

我們的應用程序越複雜，關注點之間的分離就越重要。

在100 klocs下，應用程序是一個大塊，在表單類中的業務代碼與其他任何地方一樣多，並從業務類調用表單方法。隨着許多哀嚎和咬牙切齒，我們從顯示邏輯中分離出了業務邏輯。任何需要通知用戶進展的類都會引發用戶界面沉沒的事件。而且，一段時間以來，一切與世界都是對的。

大約200 klocs，我們增加了一個數據層。我們的應用程序的架構是這樣的，我們的大部分數據一經處理就立即被處理並立即丟棄。大多數配置信息都存儲在與我們共享共生關係的第三方應用程序中。但是，在各種奇怪的角落裏，環境開始累積起來。我們結束了三個配置管理系統，所有這些都與業務邏輯錯綜複雜。通過廣泛的重寫，我們能夠將配置信息分離到各自的層中，並將流數據處理成另一層。

在250 kloc生產線附近，我們決定終止與第三方供應商的關係，並使我們的應用程序獨立運行。我們開始了大規模的重寫，並且第一次爲我們的應用程序添加了一個實際的數據庫。因爲我們在流媒體信息，數據存儲和業務邏輯之間有清晰的界限，這是一個相當無縫的整合。

現在，接近500 klocs，我們正在將應用程序轉移到基於網格的體系結構。不僅將UI與另一臺計算機上的業務邏輯分開，對應用程序發出的報價和訂單的實際計算將進行負載均衡和分攤以最大化效率。沒有n層體系結構，這將是不可能的。

在增長的每一個階段，我們都得到一個乾淨的分離或受到我們自己的通信，數據，業務和用戶界面的阻礙。在創建這個應用程序時，可能沒有比這個分離更重要的問題。

Answer 2

這是一個很好的問題！每個ASP.Net開發人員需要考慮的東西。你可能會得到很多答案，我會鼓勵這些基本常識的想法。

- 考慮簡單性和交付速度是「成功」體系結構的一部分，而不僅僅是「純度」。嘗試在堅持建築理想和實踐之間取得平衡。

- 一般來說，如你所說，將代碼分成多層是有意義的。我會建議，儘管對於特定於頁面的邏輯來說，如果它更簡單/更快，它可以留在頁面中 - 爲什麼要爲僅在一個地方使用的代碼創建通用業務對象。作爲

有人說「不成熟的優化是一切罪惡的根源。」

--keep層和複雜性降至最低，以減少編碼時間，提高可讀性和可維護性。有這個很多純粹主義者喜歡爲架構網站開發架構的網站 - 使用架構作爲解決業務問題的工具，而不僅僅是一種藝術形式，讓它成爲一種有用的工具而不是它使用您的工具。

Answer 3

代碼猴子和純潔主義者很像生活中的任何其他極端主義者。

我們有極右翼和極端的左翼。很少有人是一個人或另一個人，他們在這裏找到了一個很好的中間地帶。如果不是極端主義者，我們不知道邊界在哪裏。

就我代碼的方式而言。我傾聽純粹主義者的做法。我看到代碼猴子正在進行他們的方法。我用我的經驗來選擇一箇中間地帶，這個中間地帶給我適量的靈活性和可管理性，以及我需要製作它的時間以及我實際獲得的金錢數量。

Answer 4

保持關注的獨立性。這非常非常重要。不要將UI與Biz和Biz與數據層混合。與抽象一起工作。使用抽象也使測試（單元測試）更容易（模擬它們）。我嚴格保持它所屬的每一層。請記住，任何項目的最高成本都是維護成本。如果你混淆了擔憂，維護將成爲一場噩夢。

Answer 5

我們有一個Winforms應用程序和一個ASP.NET應用程序。他們都使用相同的Business Objects項目（約140個課程）。

Winforms項目由大約350個窗體和用戶控件類組成，其中很少的（< 10）需要關於數據庫自身的元數據。

ASP.NET項目有大約100個.aspx頁面。

我們有一個由5個類組成的數據訪問層，這些類與ADO.NET，線程和事務有關。他們將來自Business Objects的請求轉換爲SQL Server調用。

UI層（除少數需要關於表單大小的元數據的類之外）根本沒有數據庫訪問。即使極少數例外情況像其他任何事情一樣通過DAL。

業務層對數據訪問層的內部工作一無所知，當它需要數據時，只會調用DAL類的公共方法。

當談到這種事情時，我根本不是一個原教旨主義者，但我們從來沒有需要在這一點上偷工減料。

總之，100％純。總而言之，要做得更好。

我們現在必須有一個很好的理由離開這個地獄。

Answer 6

代碼越大，生命週期越長，人們在代碼上工作的差異越大（同時或在生命週期中），她在圖層中的分離越重要。一開始，這似乎有點多餘的工作，但從長遠來看，它爲自己付出了多次。

至於執行分離：這就是爲什麼你的首席程序員或技術架構師需要良好的軟技能和純技術技能。您可以嘗試從技術上強制實施分離（見下文），但最終您需要說服（或強制）開發人員以保持整個圖景的清潔。

但這並不是說技術手段來強制分離沒有用處。事實上，我發現確保「跨境電話」有點難以實現，這將使人們花更多時間思考他們在跨界面接口中真正需要什麼，從而導致更清晰的界面。如果難度是技術性的（因爲您必須使用COM或CORBA）或其他內容（您必須填寫一式三份的7頁表單）並不重要。