Web應用程序數據層dis /優勢

我想知道通過從我的Web表單分離我的業務邏輯和數據來分層我的Web應用程序的長期優勢（如果有的話）。（即表單，業務邏輯，數據不在同一個文件中，但是每個文件都在另一個文件夾中自己的類中，或者與其他類似的類一起使用）。我喜歡儘可能模塊化，並且爲了有效地這樣做，似乎將所有代碼保存在一個文件中 - 在Web表單中使組織和重用更容易。有一些功能在整個網站中使用，例如管理將在自己的類和文件中的連接。我對c＃很新，很抱歉，如果我搞亂術語。Web應用程序數據層dis /優勢

謝謝

來源

2009-08-25 Praesagus

我要去「格格不入」這裏說，儘管我始終* *分開我的代碼一樣你提出，我從來沒有真正收到過很多好處。我喜歡它沒有任何真正的原因 - 我從來沒有重做過任何特定的圖層，我的應用程序經常瞄準功能，使得特定功能背後的「業務邏輯」對於該區域是獨一無二的，因此可重用性完全是理論上的......無論如何，我每次都是這樣做的：p – JustLoren 2009-08-25 16:58:36

將代碼分成多個層帶來的好處超越了C＃語言。

如果您的數據訪問代碼保存在單獨的圖層中，可以很容易地將其調整爲使用不同的數據庫。特定於數據庫的代碼將封裝在此層中，而客戶端將與數據庫無關的接口一起工作。因此，此處的更改不會影響業務層實施。

如果您的業務邏輯保存在一個地方，您將能夠向其他應用程序提供服務，例如，爲通過Web服務提出的請求提供服務。

如果你的代碼乾淨整潔，維護工作將會保持得更低。無論何時您需要更改某些內容，您都會知道在哪裏找到責任編碼，如何更改以及如何確保更改不會影響其他代碼。對於ASP.NET而言，不關注問題的分離已經導致許多項目變成一個巨大的代碼塊 - 表示代碼執行業務決策，代碼隱藏直接與數據庫對話，只要沒有合適的業務方法存在，數據庫從許多地方被寫入，數據流遵循多條難以追蹤的路徑，未引入所有路徑的更改將破壞完整性並導致數據損壞=>結果？幾乎不可維護的代碼黑盒子，其中任何變化需要越來越多的努力，直到它停止 - 項目是「完成」。技術破產。

來源

2009-08-25 16:57:39

我們通常層我們的應用程序如下（每一層的是溶液中的一個單獨的項目，因此在一個單獨的DLL：我總是會去（第一）是有一個分層應用

表示層（JUST UI和數據綁定邏輯）
接口層到業務層（定義訪問BL的合同）
業務層實現（實際邏輯，數據驗證等）
接口層到數據訪問層（定義合同訪問DAL）
數據訪問層實施

然後，您可以使用一些工廠進行檢索相應的對象。我會看看一些庫，可能使用依賴注入，如Spring.Net或Microsoft Unity從MS模式和實踐。

的優點如下：

它所屬
沒有業務邏輯在UI（開發者必須要注意這一點）
所有的應用程序看起來邏輯的分離相同，因此知道該體系結構的開發人員將立即知道在哪裏搜索相應的可交換DAL邏輯。接口定義訪問相應圖層的合同。單元測試變得更容易，只關注BL邏輯和DAL
您的應用程序可能有許多入口點（Web界面，Winforms客戶端，webservice）。他們都可以引用相同的業務邏輯（和DAL）。
...

只是生活中不能沒有的..

來源

2009-08-25 17:00:46 Juri

Web應用程序數據層dis /優勢

回答

相關問題