問題の一部は、私が実際に質問が何であるかを知らないということであるため、これは幅広い質問かもしれません。私が知りたいのは、ページの配置（aspx）、ユーザーコントロール（ascx）、サーバーコントロール、その他のサポートクラス、ユーティリティ関数などの観点からASP.NETアプリケーションを一般的に整理する方法です。まず、既に存在すると仮定します。どこかにあるデータレイヤー（おそらく別のプロジェクト）。これは問題ではありません。私が頻繁に直面する問題は、複数のページを作成し、それらがいくつかの共通のレンダリングロジックまたはいくつかのユーティリティ関数、クラスなどを共有する必要があることに気付くことです。一部のユーザーコントロール）。これらのユーティリティクラス、共有クラス、ユーザーコントロール、サーバーコントロールなどを配置するのに最適な場所はどこですか？ここにいくつかの可能性があります。
組織を気にせず、すべての種類のファイルを並べて配置します。したがって、1つのディレクトリに、aspxファイル、一部のcsファイルなどがある場合があります。これはおそらく実際にはオプションではありません。
タイプ別にファイルを整理します。ユーザーコントロール用のディレクトリを作成し、そこにすべてのユーザーコントロールを配置するとします。OK、でもサーバーコントロールや他の通常のクラスはどうですか？それらも特別なディレクトリにあるべきですか？正しく聞こえません。これについて私が最も嫌うのは、機能（論理的に関連するコード）で作業するときは、あちこちでそれを探す必要があるということです。アプリケーションの機能と論理セクションも、何らかの方法でファイルシステムレベルでグループ化する必要があると思います。
私が欲しいのは、ページ（aspx）、ユーザーコントロール（ascx）、ハンドラー（ashx）を基本的にダミーのプレースホルダーとして、外部の訪問者の観点から論理的に整理されたディレクトリ構造に配置することです。実際のコード（ページ、ユーザーコントロールの実装、サーブコントロール、ユーティリティクラス）は、論理名前空間（アプリケーションのモジュールまたは機能によって編成された）に構造化された別のフォルダーに配置する必要があります。これを実現する唯一の方法は、<%@ Page ... %>ディレクティブを手動で操作することだと思います。
クレイジーに聞こえますか？質問しすぎですか？もっと良い方法はありますか？あなたのベストプラクティスは何ですか？あなたはいくつかの良い例を知っていますか？
編集：別のアイデア。これは、生成されたaspx、aspx.cs、およびaspx.designer.csファイルを台無しにすることはありません。私の当初の要件の1つは、aspxページを駆動するコードを自分の場所に配置し、それをカスタム名前空間階層に配置することでした。では、VSによって生成されたaspxクラスを単純にサブクラス化するとどうなりますか？MyAppというプロジェクトとその中にページがあるとしましょうMyPage.aspx。次に、VSはMyApp.MyPageから継承されたものを作成しSystem.Web.UI.Pageます。私はこのクラスをそのままにします（コードはそこに行きません）が、MyApp.SomeNamespace.SomeSubNamespace.MyPageから継承されたサブクラスを作成しMyApp.MyPageます。このようMyApp.SomeNamespace.SomeSubNamespace.MyPageにして、のサーバー制御に対応する自動生成された保護フィールドにアクセスできます。MyApp.MyPageそして、このページに関連するすべてのサポートクラスの「プライベート」名前空間全体を取得します。主な欠点はありますか？私を悩ませているもう1つの関連する問題は、この新しいcsファイルを物理的にどこに配置する必要があるかということです。Webプロジェクトには、App_Codeという標準のフォルダーがありますが、私はWebアプリケーションに興味があります。アプリケーションのルート（コードなど）にディレクトリを作成することは正しく聞こえません。