1

私はまだ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名前空間を使用します。 。このように、ihneritedコントロールを変更することは非常に簡単です。

どういうわけか、私はこの解決策について悪い 気持ちになりましたが、私はまだ経験が浅く、そのようなアプローチが合法であるかどうか、または私たちの要件に別の良い解決策があるかどうかを判断できません（後であまり多くのコードを変更せずにコントロールを変更する複数のファイル）。

このアプローチにご意見をお聞かせいただければ幸いです。

4

2 に答える 2

1

どのような変更について話しているのですか？実際に何を変更する必要があるかを知る前に、事前に各クラスから派生させるのは時間の無駄に思えます。

何かを変更する必要がある場合、その時点で派生クラスを作成し、参照を修正するのはそれほど難しくありません。これは、すべてではなく一部のインスタンスのみである可能性があります。はい、かなりの数のファイルを含むチェックインを意味する場合がありますが、適切なソース管理システムを使用している場合、それは原子的な変更であり、変更の理由は明らかです。

あなたの現在のアプローチでは、「これらは私たちが変更しなければならなかったコントロールです」という即時の方法はありません.実際に作成する必要がありました。

于 2008-12-05T10:07:29.310 に答える
0

仰るとおりです。変更、またはより適切に言えば、変更は、どのような種類のものでもかまいません。動作など。変更はジャストインタイムで行う必要があります。残念ながら、それは私の決定ではありません。一部の頑固者は働いています:)

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

私たちのプロジェクトの問題点は、データを提供するだけでなく、実際にデータを制御する一種の複雑なデータ アクセス レイヤーがあることです。これは、データ アクセス層によって提供されるロジックを含めずに、データが読み取られたり、変更されたり、削除されたり、追加されたりしないことを意味します。

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

于 2008-12-05T10:29:54.070 に答える