10

まず、これからお話しすることを言わなければなりませんSystem.ComponentModel.Component。

.NET Component Modelは (サイト サービスを介して) 個別の を定義する機能を提供するComponentsため、疎結合の方法で相互に通信でき、それぞれComponentを簡単に交換できることがわかります。

しかし、私のポイントは、そうでなければこれを達成できるということです。つまり、SWを正しいObject Oriented Programming方法で設計すればAbstract classes、Interfacesなどを使用して、言及されたすべての機能/相互運用性を達成できるということです。

では、なぜ、いつコンポーネント モデルに頼る必要があるのでしょうか?

4

2 に答える 2

8

さて、あなたはあなた自身の基本クラス、インターフェースなどでそれを行うことができます。実際、これがSystem.ComponentModelの内容とまったく同じです。これは、コンポーネントを実装して他の人の実装で使用できるようにするための、インターフェイスと基本クラスの一般的なセットです。

独自の基本クラスとインターフェイスを作成したばかりの場合は、コードとのインターフェイスを希望する人は誰でもクラスを使用する必要があります。また、2つの異なるベンダーのコンポーネントを一度に統合したい場合はどうでしょうか。

特に、WinFormsのすべてのものは、System.ComponentModelのものを使用して、フォームに配置できるコントロールを実装します。彼らはそれを表すためにいくつかのインターフェースを選択しなければならなかったので、なぜSystem.ComponentModelで定義されたものではないのでしょうか？完全にうまく設計されたものがすでに利用可能であるのに、なぜ彼らは彼ら自身を構築するのでしょうか？

于 2010-03-19T10:31:20.703 に答える
3

VisualStudioなどで使用するためのデザインタイム機能を提供できます。

「System.ComponentModel名前空間には、コンポーネントとコントロールの実行時と設計時の動作を実装するタイプが含まれています。」提供する機能は何でもかまいません（それでも、両方ともBackgroundWorker非常に異なることを行います）。ComboBoxComponent

提供されるのComponentModelはメタデータであり、その見返りは、ビジュアルデザイナーで使用できるコンポーネントを設計できることです。したがって：

public interface IDesigner : IDisposable {

        IComponent Component {get;}        
        DesignerVerbCollection Verbs {get;}
        void DoDefaultAction();
        void Initialize(IComponent component);
}

名前空間はTypeDescriptor/Convertorのものも提供し、これもデザイン時にプロパティにアクセスするために使用できます。

（System.ComponentModelを一種のIoCコンテナーとして使用できることが提案されています。これを行う人は誰も見たことがありません。おっしゃるように、優れた設計以上のものは何もありません）。

したがって、コンポーネントも提供する場合は、System.ComponentModel.Componentの使用を検討しIDesignerてください。

于 2012-11-09T12:23:06.630 に答える