12

アプリケーション コード (App_Code) を個別のファイルに分割するための一般的なガイドライン/注意点は何ですか?

時間の経過とともに、元のファイルが名前空間階層の進化とうまく一致しないことがわかりました。アプリケーション コード コンテナーを長期的に直感的に整理するにはどうすればよいですか?

ファイル分割が目指すべき目的は何ですか? コードの移植性? 関心事の分離？一般的な機能的コンテキスト? 変更頻度は？彼らはクラスとの 1 対 1 の関係を目指すべきですか?

コードを多数の小さなファイルに分割することと、少数のファイルに統合することの影響は何ですか?

私はこれについてよく考えてきましたが、すべての状況に当てはまる一般的な結論に実際に到達したことはありません.

4

5 に答える 5

13

この質問に対する答えは、多くの場合、手元にあるタスクに依存するため、絶対的なものではありません。他の人が再利用するためにある種の SDK を作成している場合、名前空間は非常に重要です。ただし、少数のクラスのみを使用して社内ツールを作成している場合、名前空間はほとんど重要ではありません。

クラス

一般的に言えば、クラスには独自のファイルが必要です。これにより、コード ソリューション内を移動する方法が簡素化され、開発と保守が容易になります (たとえば、全員が同じファイルを変更している場合、変更をマージするのははるかに困難になります)。次のような状況では、1 つのクラスを複数のファイルに分割することが許容される場合があります。

  • ネストされたクラスがある場合、ネストされたクラスごとに独自のファイルを持つことができます。

  • デザイナー コードなど、クラスに自動生成された部分がある場合。

  • 非表示プロパティの共通セットやインターフェイスの共通実装など、クラスに固定部分がある場合。

私たちのプロジェクトの 1 つで、多くのクラスが公開するインターフェースの共通の実装があります。多重継承がないため、クラスごとに追加のファイルを自動生成するミックスイン アプローチを採用しています。これは、自動ではなく手動で行うことができました (元々はそうでした)。

他の状況もありますが、これはやや主観的であり、独自のプロジェクトの要件に依存しています。

名前空間

名前空間は、通常、タイプの適切なグループ化に焦点を当てる必要があります。名前空間は、開発者が探しているものを直感的に見つけられるようにする必要があります。多くの小さなプロジェクトでは、 のような単一の名前空間MyAwesomeToolで十分ですが、多くのクラスを含む大規模なプロジェクトでは、より論理的なグループ化が必要になります。SDK や .NET BCL などの大規模なプロジェクトは、名前空間に依存して、そうでなければ圧倒的に大規模な型のコレクションを分解します。各名前空間レベルは、System.Windows.FormsまたはSystem.Drawingまたはなど、そこにある可能性のある追加情報を提供しますMicrosoft.VisualBasic。

名前空間を作成するときは、その名前空間と関連するプロジェクトの目的をすべて考慮する必要があります。プロジェクトが社内で小規模な場合は、型をグループ化するために必要なだけなので、好きなように名前空間を呼び出します。プロジェクトが外部から見える場合、または大量のタイプが含まれている場合は、他のユーザーが探しているタイプを直感的に見つけられるように、論理的で意味のあるグループ化について慎重に検討してください。

結論

すべての状況で機能する厳密で迅速なルールはありません。コードをファイルにどのように配置するかは、独自の開発プロセスに関連しており、あなたとあなたのチームに影響を与えます。1 つのファイル内のすべてのクラスを使用して開発するのは非常に困難ですが、コンパイルされた製品はまったく同じように動作します (1 つのファイルのアプローチがエラーにつながらない場合)。一方、名前空間の配置は将来の開発との消費者に関連します。そのため、間違った結果はより深刻になる可能性があります。

  • 現在の開発と将来の保守を簡素化する方法でクラスを編成することを目指してください。
  • すべての開発を簡素化し、必要に応じてエンド ユーザーのエクスペリエンスを簡素化する方法で名前空間を整理することを目指します。
于 2009-01-26T23:14:08.293 に答える
6

クラスとソース ファイルの間には 1 対 1 のマッピングが必要です。

名前空間は、1 つまたは複数のクラスを含むパッケージと考える必要があります。可能であれば、これらを Visual Studio プロジェクト ウィンドウでフォルダー/フィルターとして表すと便利です。

個別のファイルに分割することでメリットがあると思われる大きなクラスが見つかった場合は、代わりにクラス自体をリファクタリングして分割することを検討してください。

これに対する (許容可能な) 例外は、Visual Studio が別のファイルに配置する UI を生成するコードです。これを独自のファイルに残し、可能な限り透過的なエディター所有のファイルとして扱うことをお勧めします。

于 2009-01-26T22:56:14.010 に答える
4

私が見たほとんどの推奨事項は、すべてのパブリック型は独自のファイルに配置する必要があり、名前空間はアプリケーションのフォルダー構造を表す必要があると述べています。

于 2009-01-26T22:55:34.913 に答える
1

クラスに関する限り、私は Java のルールに従う傾向があります。「ファイルごとに 1 つのパブリック クラス」というルールに従います。そのパブリック クラスが唯一のユーザーである場合は、パブリック クラスにプライベート クラスを含めることができます。(ただし、列挙型はこれをあまり重要視していません); ただし、同じ名前空間内の多くのパブリック クラスで使用されている場合は、独自のファイルに配置します。

私は、次のように名前空間を使用する傾向があります。

MyAwesomeApp.UI
MyAwesomeApp.Business
MyAwesomeApp.Data

レイヤーの分離を反映します。

于 2009-10-02T17:35:18.780 に答える