沒有業務邏輯層的ASP.Net 2.0應用程序？

Question

在沒有BLL（業務邏輯層）的情況下，如果有一個ASP.Net 2.0應用程序，它是「可接受的」嗎？

1. SQL Server數據存儲&存儲過程
2. 數據鏈路層（強類型表適配器）連接到存儲的特效
與後面的代碼和ObjectDataSource
3. 表示層ASPX頁直奔DLL

連接

即使業務邏輯完全在演示文稿的代碼後面驗證，BLL總是更可取的嗎？不使用BLL有什麼潛在的缺點？

Answer 1

就像其他所有環境一樣，它取決於系統的使用。你需要問你自己的問題是：

1. 將這個積極發展
2. 這是將要使用在多年的歷程，並擴大了
3. 是應用程序的擴展未知因此無限

真的，它歸結爲懶惰。您希望花費多少時間從UI重新使用系統？因爲沒有業務層就意味着您的用戶界面中可能存在許多頁面的重複規則。

然後再次如果這是一個概念驗證或短期演示或類項目。採取簡單的方法。

Answer 2

只要你瞭解後果，這是可以接受的。 BLL的主要原因是在整個應用程序的其他地方重新使用該邏輯。

如果您在表示代碼中包含所有驗證邏輯，那麼您確實很難在應用程序中的其他位置重新使用。

Answer 3

可以接受嗎？取決於你問及你的要求是什麼。這個應用程序是您和其他一些人使用的內部一次性應用程序嗎？也許這夠好。如果它的目的是要成爲一個可以隨時生長和維護的生產就緒型企業應用程序，那麼您可能需要預先投入更多的努力來構建可維護的應用程序。

分離問題是構建可維護應用程序的關鍵設計技術。通過將演示文稿，業務和數據訪問邏輯混合在一起，您最終可能會遇到一個非常脆弱的難以改變的應用程序體系結構。

Answer 4

這取決於。如果您的業務邏輯處於您的點擊事件和頁面加載中，則無法接受。

看起來你的業務邏輯是在DAL內的某個地方（例如，存儲過程等），只要你一致，沒關係。只要你非常非常確定你的客戶端總是正在使用SQL Server，那麼這種方法不成問題。

我知道一個同事誰擁有所有他的商業邏輯在存儲過程中，他的意見大多是瘦客戶機後端數據庫：他一直是非常成功的與他所銷售的產品。但那只是因爲他非常符合它。

Answer 5

如果應用程序是通用應用程序，那麼業務邏輯層也可以用於完整的其他應用程序。就像我通常在其他應用程序中使用我的CMS相關的BLL類。