C＃アセンブリからコントロールを後で変更するための柔軟なベースを設定する方法は？

Question

私はまだC＃を使い始めており、WPFと、フレームワークにまだリリースされていないWPF DataGrid Toolkit（CodePlexを参照）も使用するプロジェクトに取り組んでいます。プロジェクトの性質上、後でアセンブリの一部のコントロールを変更することは100％確実です。 私の同僚は、プロジェクトのネームスペース内のデータグリッドからすべてのコントロールを再定義し、アセンブリネームスペースの特定のコントロールを変更することにしました。 使用する代わりに： clr-namespace：Microsoft.Windows.Controls.Primitives; assembly = WPFToolkit clr-namespace：Microsoft.Windows.Controls; assembly = WPFToolkit 独自のxxx.Controlsおよびxxx.Controls.Primitives名前空間を使用します。 この方法では、変更されたコントロールを変更するのは非常に簡単です。

どういうわけか、この解決策について悪い 気分になったが、まだ経験の浅いので、そのようなアプローチが合法かどうかわからないまたはそうでない場合、または要件に対する別の良い解決策がある場合（複数のファイルのコードをあまり変更せずに後でコントロールを変更する）

このアプローチに意見を述べていただければ幸いです。

Answer 1

どのような変更について話しているのですか？実際に何を変更する必要があるかを知る前に、各クラスから先制的に導き出すのは時間の無駄のようです。

何かを変更する必要がある場合、その時点で派生クラスを作成して参照を修正するのはそれほど難しくないはずです-これは some すべてではなくインスタンス。はい、それはかなりの数のファイルを含むチェックインを意味する可能性があります-しかし、賢明なソース管理システムを使用している場合、それはアトミックな変更であり、明らかに変更されますなぜ。

現在のアプローチでは、即時の<！> quotはありません。これらは変更する必要があるコントロールです！<！> quot; -<！> quot;ジャストインタイム<！> quotで行う場合;方法では、実際に作成しなければならなかった派生コントロールを見るだけでわかります。

Answer 2

同意します。変化、またはより良い言い方をすれば、変化はどんな種類のものでもありえます。行動など。そして、変更はジャストインタイムで行われるべきです。 残念ながら、それは私の決定ではありません。頑固な人もいる：）

しかし、興味深いのは、アイデア全体に対してまったく異なるアプローチが存在する場合です。 たとえば、DataGridがあり、プロジェクトが進化した今、dataGridの行の検証動作を大幅に変更する必要があります。 これは、多くのコントロールにも適用できます。

プロジェクトの問題は、データを提供するだけでなく、実際にデータを制御する複雑なデータアクセスレイヤーがあることです。つまり、データアクセスレイヤーによって提供されるロジックを含めない限り、d ataは読み取り、変更、削除、または追加されません。

例として、datagridは行を直接削除しませんが、代わりに削除動作を上書きし、データアクセスレイヤーを削除して削除します。バインディングでは、これは今のところかなりうまく機能します。 この種のシナリオは、CRUD操作、検証などに関して、将来的に他の多くのものに適用されます。