2010-10-28 57 views
0

如何構建一個大型項目,大部分業務邏輯已經存儲在存儲過程中?從ASP轉向,業務邏輯被困在存儲過程中

這裏是背景的一點點:

我們正在從傳統的ASP遷移到ASP.NET(VB)和幾乎所有的業務邏輯內部存儲過程。因爲我的老闆不想(太昂貴,需要太長時間,沒有「真正的」附加價值),所以將邏輯擺脫出來幾乎是不可能的。

我在想製造由ASPX頁面的表示層,業務邏輯層/數據訪問層 將基本上得到的數據,並與現有的存儲過程和業務實體層0​​將作出的類交互(用於實體和集合)包含這兩層之間交互的信息。

我想製作這些圖層的原因是爲了能夠重複使用大部分代碼而不重複它。

我想就您如何構建新應用程序發表意見。

+0

你提出的結構是好,除了業務邏輯和數據訪問應該理想地分隔,但無疑將是困難的,如果其中大部分包含在格蘭現有的存儲特效。 – 2010-10-28 14:25:29

回答

1

注意不要過分熱衷於「使邏輯擺脫」存儲過程。存儲過程在許多應用程序中都有有效的作用。如果明智地使用它們,它們通常是封裝某些邏輯的最佳位置。關於使用存儲過程的一個很好的答案 - Use of StoredProcs in an application

在.NET方面,您的設計聽起來很合理。您的DAL可以環繞存儲過程層並抽象業務對象的持久性。如果您仍然需要獨立的「業務邏輯」層,那麼這應該與DAL分離。

對於前端,您可能需要考慮ASP.NET MVC而不是ASP.NET webforms。 MVC是一種適合於基於網頁的應用程序的自然模式,對於經典的ASP網站來說,它往往是一個更容易的遷移目標。

1

將業務邏輯從數據訪問代碼中分離出來是一個好主意......特別是在存儲過程中。然而,問題在於你的老闆可能不會和你一起看。他認爲只是將asp代碼移入asp.net而不修改後端。重新構建系統將花費大量時間和成本...並且存在很多潛在的引入錯誤等的問題。

第一步是試圖說服你的老闆,這個。

2

以及你的想法是正確的prefectly邏輯..Business不應該在存儲過程..我不是很有im在開發方面有豐富的經驗,現在我正在研究那些擁有SP中所有業務邏輯的項目,甚至有超過1000行代碼在那裏,還有動態sql查詢在那裏,相信我,我挑戰任何一個你不能說的天才調試SP's sp中的單行更改很痛苦,並且它花費很多時間來理解效果和更改。從SP

以及更好的DAL seprate