UI(デザイナー/エディター)ロジックをパッケージフレームワーク(Visual Studioパッケージなど)から分離する最良の方法は何ですか
-
03-07-2019 - |
質問
ここで懸念を分けたいと思います。カスタムXMLデザイナー、オブジェクトモデル、検証などのすべてのUIロジックを作成して、個別のアセンブリに埋め込みます。次に、パッケージフレームワークはデザイナー情報を登録し、UIサービスを要求するだけで、すべてが魔法のように機能します。
この方法では、UIデザイナーを変更する必要があるときに、パッケージフレームワーク(Visual Studioパッケージ)アセンブリを操作する必要がありません。
この質問は、プラグインなど、UIロジックをロードするSkeletonフレームワークからUIロジックを分離する必要がある場合にも適用されます。
ServiceProviderモデル、プラグインモデル、またはその他の選択肢がいくつかあります。
サンプル、パターンの提案、リンクは大歓迎です。
更新1:私が探しているのは、次のような考えです-" Prism(Composite WPF)は法案に適合しますか?上記のように懸念の分離を行うプロジェクト/アプリケーションで作業した人はいますか?など" (私はまだ答えを探しています)
解決
エディターをロードするVSPackageを作成しました。エディターは別のアセンブリに配置され、定義したインターフェイスを実装します。 VSPackageはインターフェイスで機能するため、エディター(およびそのアセンブリ)に加えた変更は、インターフェイスを変更しない限り、VSPackageに影響しません。
他のヒント
MVC の懸念の分離に非常によく似ている縫い目について尋ねていることパターンは強制しようとします。
ASP.NET MVC は既にプレビュー5 。
主にWeb用ですが、WinFormsでも使用することを計画していると思いますが、わかりません。
モデルビュープレゼンターパターン