質問

webforms / winformsで生成されたコードシナリオ以外の部分クラスの適切な使用法はありますか?それとも、この機能は基本的にそれをサポートするためのものですか?

役に立ちましたか?

解決

一部は、生成されたコードとプログラマーコードを混合するシナリオ(WebForms、WinForms、LINQ-to-SQLなど)をサポートすることです。

これを使用する理由は他にもあります。たとえば、扱いにくい大きなファイルに大きなクラスがあるが、クラスに論理的に関連するメソッドのグループがある場合、部分クラスはファイルサイズをより管理しやすくするためのオプションです。

他のヒント

コード生成は、部分クラスの背後にある推進力でした。絶えず変化するコード生成クラスが必要ですが、開発者はクラスの一部としてカスタムコードを提供でき、クラスを強制的に変更するたびにオーバーライドされることはありません。

たとえば、WinFormsまたはTyped-DataSets(またはそれに関するデザイナー)を使用します。デザイナーに変更を加えるたびに、対応するコードがファイルにシリアル化されます。ジェネレータが何も知らないいくつかの追加メソッドを提供する必要があるとしましょう。生成されたファイルに追加した場合、変更は次回生成されたときに失われます。

現在取り組んでいるプロジェクトでは、すべてのDAL、BLL、およびビジネスエンティティに対してコード生成を使用しています。ただし、ジェネレータは情報の75%しか取得しません。残りの部分は手動でコーディングする必要があります(たとえば、カスタムビジネスロジック)。すべてのBLLクラスにはSelectAllメソッドがあるため、簡単に生成できます。ただし、顧客のBLLにはSelectAllByLocationメソッドも必要です。これはすべてのBLLクラスに一般的ではないため、これをジェネレータに入れることはできません。したがって、すべてのクラスを部分クラスとして生成し、別のファイルでカスタムメソッドを定義します。構造が変更された場合、または何らかの理由でBLLを再生成する必要がある場合、カスタムコードは消去されません。

私が作成したカスタムコントロールのさまざまなサブ要素を分離する手段として、部分クラスを使用します。また、エンティティ作成ソフトウェアと併用すると、LLBLGenなどの製品でクラスの生成バージョンや、ユーザーが編集したカスタムバージョンを作成できます。これらは、エンティティを再生成する必要がある場合に置き換えられません。

私はしばしば部分クラスを使用して、ネストされた各クラスに独自のファイルを与えます。ほとんどの実装が1つのクラスでのみ必要とされるアーキテクチャに取り組んできたため、それらのクラスをその1つのクラスにネストしました。部分クラス機能を使用し、各ファイルを独自のファイルに分割することで、ファイルの保守を容易にすることは理にかなっています。

また、在庫オーバーライドのグループ化または在庫プロパティセットの非表示にも使用しました。そういうもの。これは、在庫の変更を混ぜるのに便利な方法です(ファイルをコピーして、部分クラス名をターゲットクラスに変更するだけです-もちろん、ターゲットクラスも部分クラスになっている限り)。

部分クラスのもう1つの使用方法は、部分メソッドを利用して、条件付きコンパイルを使用してメソッドを選択的に非表示にすることです。これは、デバッグモード診断コードまたは特殊な単体テストシナリオに最適です。

キーワード「" partial"」を入力すると、他の部分クラスで抽象メソッドのような部分メソッドを宣言できます。 Intellisenseを利用してそのメソッドの実装を作成できます。

条件付きビルドステートメントで一部を囲むと、デバッグ専用コードまたはテストコードを簡単に切断できます。以下の例では、DEBUGモードでLogSomethingDebugOnlyメソッドが呼び出されますが、リリースビルドでは、メソッドがまったく存在しないようです-分岐の束や複数の条件付きコンパイルブロック。

// Main Part
public partial class Class1
{
    private partial void LogSomethingDebugOnly();

    public void SomeMethod()
    {
        LogSomethingDebugOnly();
        // do the real work
    }
}

// Debug Part - probably in a different file
public partial class Class1
{

    #if DEBUG

    private partial void LogSomethingDebugOnly()
    {
        // Do the logging or diagnostic work
    }

    #endif
}

LINQ to SQLは、部分クラスをうまく利用して、デザイナーが生成したコードを拡張します。通常、デザイナーが作成したコードで使用される部分クラスのこのパターンを見つけると思います。

部分クラスは非常に役立つことがわかりました。通常、自動生成されたクラスを拡張するために使用されます。重い単体テストを使用した1つのプロジェクトでそれらを使用しました。私のUTクラスには複雑な依存関係があり、複数のクラスにコードを分離することはあまり実用的ではありませんでした。もちろん、inheritance \ compositionを使用する方が良いですが、場合によっては部分的なクラスが役立ちます。

前述したように、これもコードのにおいだと思います。

クラスが非常に大きく、より多くのファイルに分割する必要がある場合、単一の責任原則を破り、多くのことを実行していることを意味します。 大きなクラスは、連携する小さなクラスに分割できます。

部分的なクラスまたは領域を使用してコードを整理する必要がある場合は、それらを独自のクラスに含める必要があるかどうかを検討してください。読みやすさが向上し、コードの再利用が増えます。

もう手遅れかもしれませんが、2セントも追加させてください:

*:大規模プロジェクトで作業する場合、クラスを別々のファイルに分散させることにより、複数のプログラマーが同時に作業することができます。

*。VS.NET生成クラスのコード(拡張機能用)を簡単に記述できます。これにより、システム生成コードをいじることなく、必要なコードを作成できます

現在、クライアントからの着信ファイルを処理するプログラムがあります。各クライアントのコードが独自のクラスライブラリプロジェクトに含まれるように設定されており、クライアントが使用することを選択した形式を処理する方法を知っています。

メインコードは、ライブラリ内のクラスが実装する必要があるかなり広範なインターフェイスを定義することでライブラリを使用します(おそらくいくつかの個別のインターフェイスである必要がありますが、今では変更するには遅すぎます)。時には、通常は慎重であると考えるよりも、同じクラスでより多くのコードが必要になります。部分クラスを使用すると、クラスを多少分割できます。

比較的複雑なUserControlsでは、イベント処理のものを1つのファイルに、ペイントとプロパティを別のファイルに配置します。部分クラスはこれに最適です。通常、クラスのこれらの部分は比較的独立しており、ペイントとイベント処理を並べて編集できるのは素晴らしいことです。

私は数年前にプロジェクトに取り組みました。そこでは、大量のコードを含む型指定されたDataSetクラスがありました。DataTablesのメソッド、TableAdaptersのメソッド、TableAdapterインスタンスの宣言、などです。誰もが頻繁に作業しなければならないプロジェクトの大きな中心点であり、部分的なクラスコードファイルをめぐる多くのソース管理の競合がありました。

コードファイルを修正または6つの部分クラスファイルに分割し、機能ごとにグループ化して、小さな部分で作業できるようにし、少し変更するたびにファイル全体をロックする必要がないようにしました。

(もちろん、排他ロックのソース管理システムを使用しないことで問題を解決することもできましたが、それは別の問題です。)

一般的に、私はそれをコード臭と考えています。

クラスがそれほど複雑な場合、おそらく再利用可能な小さなコンポーネントに分割できます。

または、あるべき継承階層がないことを意味します。

コード生成のシナリオには適していますが、コード生成は別のコードの匂いだと思います。

私はゲームに遅れています...しかし、たったの2セントです...

1つの用途は、既存のレガシーコードベースの既存のgodクラスを複数の部分クラスにリファクタリングすることです。部分クラスを含むファイル名に対して適切な命名規則が守られている場合、コードの発見可能性を改善できます。これにより、ソースコードリポジトリも削減される可能性があります-ある程度まで解決およびマージします。

理想的には、神のクラスは複数の小さなクラスに分割する必要があります-それぞれが単一の責任を持ちます。中規模から大規模のリファクタリングを実行すると、混乱を招く場合があります。そのような場合、部分クラスは一時的な救済を提供できます。

修正、マットが指摘したように、部分の両側は同じアセンブリにある必要があります。 私の悪い。

データアクセスレイヤーで使用します。マッパーなどの生成されたクラスは、パーシャルをクエリします。たとえば、生成されない派手なロードを行うためにマッパーメソッドを追加する必要がある場合は、カスタムクラスに追加します。

最後に、ビジネス層でデータ層を使用するプログラマーは、必要なすべての機能を備えた1つのクラスのみを参照します。また、データソースが変更された場合、カスタムパーツを上書きせずに汎用パーツを簡単に生成できます。

部分クラスの使用法を見つけました。クライアントにデータを渡すために使用する[DataContract]クラスがあります。クライアントが特定の方法でクラスを表示できるようにしたかった(テキスト出力)。そこで、部分クラスを作成し、ToStringメソッドをオーバーライドしました。

既存のコードを壊さずに個別の要素にリファクタリングすることがほぼ不可能になる可能性がある、非常に古いコードが動作している場合があります。

より純粋なアーキテクチャを作成するオプションや時間を与えられない場合、部分クラスを使用すると、必要に応じてロジックを簡単に分離できます。これにより、既存のコードは同じアーキテクチャを使用し続けることができ、より具体的なアーキテクチャに一歩近づきます。

#region セクションを使用したことがある場所であれば、おそらく部分クラスの個別のファイルとしてより意味があります。

私は個人的には、静的メンバーが1つのファイルに入り、インスタンスメンバーがもう1つのファイルに入る大きなクラスに部分クラスを使用します。

編集:Visual StudioのDSLツールは部分クラスを使用します。

したがって、これは多くの自動生成コードが使用する機能です。 #regionを使用する代わりに、自動生成されたコードは1つのファイルに行き、ユーザーコード(カスタムコードとも呼ばれます)は別のディレクトリに移動します。

組み合わせることができるこの選択肢があるのは良いことですが、-with inheritanceを強制的に使用することはありません

また、いくつかのクラスのロジックをいくつかのディレクトリに分けるのも便利です。もちろん、マシンについても同じですが、ユーザーの読みやすさを向上させます。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top