ASP.NET項目組織

Question

這可能是一個廣泛的問題，因爲部分問題是我實際上不知道問題是什麼。我想知道的是，如何在頁面（aspx），用戶控件（ascx），服務器控件和其他支持類和實用程序函數等的位置方面通常組織ASP.NET應用程序。首先，讓我們假設已經存在某處的某個數據層（可能位於不同的項目中）。這不是問題。 我經常遇到的問題是，創建幾個頁面，並意識到他們需要共享一些常見的渲染邏輯或一些效用函數，類等。另一個典型情況是某些頁面變得太大，以至於看起來很方便將它們分開（說進入一些用戶控制）。什麼是放置這些實用程序類，共享類，用戶控件，服務器控件等的最佳位置？這有幾種可能性。

真的不關心任何組織，並把所有類型的文件彼此相鄰。所以在一個目錄中，你可能有一個aspx文件，一些cs文件等。這可能不是一個真正的選擇。

通過類型組織文件。假設您爲用戶控件創建一個目錄並將所有用戶控件放在那裏。好的，但是服務器控件和其他常規類呢？他們是否也應該在特殊目錄中？這聽起來不對。我最不喜歡的是，當你使用一個特性（邏輯上相關的代碼片段）時，你必須在整個地方捕捉它。我認爲應用程序的功能和邏輯部分也應以某種方式在文件系統級別進行分組。

我想擁有的頁面（aspx），用戶控件（ascx）和處理程序（ashx）基本上作爲虛擬佔位符坐在目錄結構從邏輯上組織根據的角度來看外部訪問者，而實際代碼（頁面，用戶控件實現，服務控件和實用程序類）應放置在結構化爲邏輯名稱空間的不同文件夾中（由應用程序的模塊或功能組織）。在我看來，實現這一目標的唯一方法是手動操作<%@ Page ... %>指令。

聽起來很瘋狂嗎？我問得太多了嗎？有沒有更好的辦法？你最好的做法是什麼？你知道一些很好的例子嗎？

編輯：另一個想法。這並不妨礙生成的aspx，aspx.cs和aspx.designer.cs文件。我原來的要求之一是我想將驅動aspx頁面的代碼放到我自己的位置並將其放到自定義名稱空間層次結構中。那麼，如果我簡單地繼承了VS生成的aspx類呢？假設我有一個名爲MyApp的項目，並在其中包含MyPage.aspx頁面。 VS然後創建從System.Web.UI.Page繼承的MyApp.MyPage。我離開這個類（沒有代碼會去那裏），但創建一個子類，如MyApp.SomeNamespace.SomeSubNamespace.MyPage，從MyApp.MyPage繼承。這樣MyApp.SomeNamespace.SomeSubNamespace.MyPage將可以訪問相應的MyApp.MyPage服務器控件自動生成的保護領域，我會得到一個完整的「私人」的命名空間這是與此頁面中的所有支持類。任何主要缺點？另一個困擾我的相關問題是這個新的cs文件應放在哪裏？在web項目中，有一個名爲App_Code的標準文件夾，但我對Web應用程序感興趣。在應用程序的根目錄（例如Code）中創建一個目錄聽起來不對。

Answer 1

記住，你可以創建一個實際上並不符合任何標記網頁類。我們經常創建我們的實際UI頁面從中繼承的基本頁面。這是組織「基本」頁面功能的簡單方法。然後，當您創建.aspx頁面時，讓它們從基本頁面類繼承，而不是System.Web.UI.Page。

我們通常把我們的基本頁面。如果cs文件是一個小項目，或者對於稍大的項目，我們將在它們所在的位置創建一個「共享」或類似的目錄，然後將它們導入頂級目錄。

但是，我們也有一個巨大的企業Web項目，我們只需將我們的webcontrols和基礎頁面構建到名爲CompanyName.Web.UI的類庫中，並具有幾個子命名空間。我們所有的實際網站項目導入該程序集和控件的所有代碼等都在其他地方。這聽起來像它可能是一個很好的選擇。

如果您還記得您的.aspx代碼隱藏文件可以從任何類文件繼承，它應該使您更容易組織。