winforms - Win32/.NET Win フォームにおける UC(User component) の概念

Question

数年前、私は会社で Web 開発者として働くことになりました。私の最初の Sirius Web 開発の仕事 (ASPx/C#) があるので、非常にエキサイティングで、開発者の観点からその世界について多くのことを学びました。

そのグループでは、ページ UC (ユーザー コントロール) に読み込まれるページの概念がありました。すべての言語のすべての Web 開発チームで同じであるかどうかはわかりませんが、そうであると仮定します。

契約が終了し、win32 の「winForm」アプリケーションを開発するために戻ってきました。

しかし、それら以来、私はそこで学んだwin32開発に同じ原則を適用しようとしました。つまり、フォームにロードするUC（ビジュアルユーザーコントロール）の束を持つことを意味します。これらは通常のビジュアル コンポーネントであり、ツールボックスに読み込まれず、コードはプロジェクトで使用できますが、コンポーネントはフォームで開発されず、そこに読み込まれます。

このアプローチについての意見、これと同様またはそれ以上に行っていること、および開発をスピードアップし、コードの再利用を増やすのに役立つ改善について知りたいです。それがすべてです。

Answer 1

Winforms でレイアウト コンポーネントを使用している場合、これは許容できるアプローチかもしれませんが、Web と Windows フォーム (注: WPF ではありません!) を区別するのは、前者では多くの「合成」を行うことです。これが、UserControl の概念が非常に便利な理由ですが、後者では非常に洗練されたコントロールを操作します (たとえば、サード パーティ - 私の最後のギグでは、Infralutionという小さな会社を介して信じられないほどのグリッド コントロールを使用しました) 。

レンダリング モデルが Web とは少し異なるため、主な問題はレイアウトに関するものです。私はあなたのアプリケーションについて何も知りませんが、それが「機能する」かどうかが最も重要です。この場合、FlowLayoutPanel や TableLayoutPanel などを適切に使用していると仮定します。

より標準的なルートに進みたい場合は、単にコンポーネントを作成するだけでなく、継承モデルを使用してアプリケーションをより堅牢な方法で合成する方法を見てください。「UserControl」タイプのコンテナーを持つ基本 Form クラスを使用します。コンポーネントは移動し、アプリケーションの実行中にある種のインターフェースベースの依存性注入を使用してそれらを交換します。

最後に、オープン ソースの Windows フォーム アプリケーションをいくつか見て、共通の UI と再利用可能なコンポーネントがすべてのアプリケーションの目標であるため、自分自身に負担をかけすぎていないかどうかを確認してください。Microsoft の Patterns & Practices は肥大化しているといつも思っていましたが、いくつかの良いアイデアがあり、Microsoft が発表したComposite UI Application Blockのいくつかのアプローチを研究する必要があります。

最後ではありませんが、もう 1 つ追加したいことがあります。Web 開発の時代から多くの概念を取り戻し、デスクトップ アプリケーションにそのような力を与える WPF をじっくりと見てください。