我們有一個我們想用ASP.NET重寫的ASP經典ERP（非常大的應用程序）。需要大型ASP.NET應用程序的幫助
我正在尋找一種方式來組織應用程序，所以我們將能夠將每個程序/網頁（超過400）彼此分開。每個程序都需要獨立，因爲許多開發人員將同時在該項目上工作。
Visual Studio似乎爲每個程序集都生成一個DLL，所以我想知道是否每個DLL都有一個項目是一個很好的解決方案。
Ex。 ：
Customers.aspx + Customers.aspx.vb（編譯）用於呈現
Customers.DLL爲對象實體
CustomersManager.DLL業務邏輯
CustomersData.DLL用於數據訪問
這樣，我們就可以單獨部署每個程序而不會改變其他程序。我們也將有超過一千個DLL來管理...
它似乎是一個大型應用程序的好方案？ 任何人有更好的主意？
感謝
源代碼控制正是發明了一種具有多發於大解決方案並行工作的目的。我很欣賞具有可獨立部署的組件的價值，但由於需要維護的獨立組件的數量接近數百和數千，可能會損失價值？
將應用程序分離爲單獨的表示/業務邏輯/ DAL DLL在每個模塊的基礎上確實有意義，但通常不是基於每個頁面。
考慮可能共享代碼並從那裏開始的應用程序的不同功能區域（每個項目都有一組項目）。
我一定會尋找一種方法來管理源控制級別上的這種情況。感謝您的幫助。 – Jason 2010-10-18 19:32:55
這似乎對我來說是一個巨大的難以控制的噩夢。
我一直是幾個大型.Net項目的一部分，最傑出的工作方式，如JeffN825，使用某種源代碼控制，以及直接支持模型（數據庫）的類。項目根目錄下
文件夾可以幫助你在邏輯上分成東西「/客戶」，「/訂單」等
如果你想單獨的項目爲課程，這也是做了相當多。有一個包含所有數據庫對象的單獨項目。爲業務邏輯創建另一個項目。實際上，如果你覺得你需要它，創建幾個業務邏輯項目「CustomerBO」，「OrderBO」等。
但管理超過1000個dll及其關聯的網頁......這將是一場噩夢。
我認爲問題是詢問是否爲每個頁面的每一層都有一個獨立的DLL是一個好的體系結構，如果沒有其他原因，除Visual Studio之外的其他原因會嘗試停止嘗試加載100個單獨的項目（我不寒而慄，想到會做什麼，以及維護所有這些DLL是多麼的不可能）。現在一個更合理的解決方案是爲每個圖層分配一個DLL，並將每個頁面的代碼分離到不同的文件中並使用源代碼管理系統。這將允許開發人員共享代碼，即使是最差的源代碼管理系統也是如此。如果您的源代碼管理系統像TFS，SVN，Git一樣支持不錯的分支/合併支持（即不是SourceSafe），您甚至不用擔心人們在模擬同一個文件上工作，然後您可以按功能組織代碼而不是頁面。我從這個問題猜測，有可能是一個天文數量的重複代碼，可以簡化並通過打破僵化的網絡代碼連接和重用代碼更容易維護。看看會有多少代碼會是令人驚訝的。您可以在UI端執行相同的操作，並明智地使用用戶控件來封裝共享功能。再加上從ASP轉移到.NET，你可以獲得像SiteMap控件這樣的應用程序，它也可以減少代碼佔用量。
你能引入新的軟件模式嗎？ – jpg 2010-10-18 19:07:20