「優れたプログラミング プラクティス」についてさらに質問があります。私は本当に大きなプロジェクトを始めたばかりです。私は WebGui を使用しています (簡単に言えば、Web では WinForms です) - しかし、それは重要ではありません。
、などTextBoxの何百万ものコントロールを備えた何百万ものフォームを作成しています。動作や外観を変更する必要がある場合があります。すべてのコントロールで変更することは不可能です。プロジェクトを柔軟にしたいので、アイデアがあります..NumericUpDownDateTimePickerDateTimePicker
文字列、数値、日付、バイトなど、すべてのタイプのカスタムコントロールを個別に作成し、その中に TextBox を配置します。そして、すべてのフォームに TextBox ではなく MyTextBox を配置します。実際、その MyTextBox は単なる TextBox になりますが、そこで何かを変更すると、すべてのコントロールが変更されます。
それはプログラミングの良い、人気のある練習ですか?
WPF の場合、これはスタイルとテンプレートを使用して非常に簡単に実現できます。Winformsではこれは不可能なので、コントロールから派生させてUIで独自のカスタムコントロールを使用するというアプローチは、変更を一元的に管理するのに役立つ実用的なアプローチだと思います。
コントロールがプログラムで手動で作成された場合は、代わりに、ファクトリー クラスを使用して、単に新規作成するのではなく、ファクトリーにコントローラー オブジェクトを作成させることができます。ただし、開発者がコントロールの作成を制御できないため、コントロールをドラッグ アンド ドロップして UI を作成する場合、これは不可能な場合があります。
どちらのアプローチを選択する場合でも、基本的な目標は、コントロールの作成ロジックを一元化することです。
はい、標準コントロールが要件を満たさない場合、これは GUI 開発の完全に通常のプログラミング手法です。
ほとんどの開発者は、柔軟性を高めるためにサードパーティ製のコントロール スイートを入手しています。購入することのメリットは、コア コントロールを自分で構築することのメリットよりもはるかに重要です。
companyTextBox、companyDatePickerを行った場所で働いたことがありますが、うまくいきました。いくつかのコントロールが .Net バージョンで改良されたため、これらの基本クラスのコントロールにはいくつかの手術が必要でした。減価償却されたコントロールは、フレームワークのバージョンに依存するものとして残されました。
特別なこととして、CodeProject、CodePlex、Code.Google.com などの優れたカスタム コントロールについて多くの調査を行い、それらを現在取り組んでいるプロジェクトに実装しています。それ以外の場合は、ストック標準コントロールまたは私が使用している会社の一連のサードパーティ コントロールを使用します。
私のアドバイスは、サード パーティ製のコントロール スイートを入手し、サード パーティ製のコントロールに基づいて再利用可能なユーザー コントロールを大量に作成することです。このように、ユーザー コントロールをフォームにドラッグ アンド ドロップすることで、200 のフォームのほとんどを作成できます。各ユーザー コントロールに、フォームの Create、Retrieve、Update、および Delete メソッドを備えたインターフェイスを実装して、一般的にユーザー コントロールを操作します。