Prism V4:UnityまたはMef?
-
30-09-2019 - |
質問
私がダウンロードしました プリズムV4 インストーラーを実行しました。私はディレクトリに入り、次の2つのバッチファイルを実行しました。
- デスクトップのみ - MEF QuickStart.BATでモジュール性を開きます
- デスクトップのみ - Unity QuickStart.BATでモジュール性を開きます
これらのアプリケーションをコンパイルするとき、本当の違いはありません。 MEF対Unityを検索しましたが、長所/短所を見つけましたが、プリズムで使用する「より良い」(そしてそれが主観的であることは知っている)かどうかを明確に述べているものはありません。おそらく、私が自分の要件をリストした場合、誰かが私に使用する正しいテクノロジーを私に示すことができると思います(たとえそれがプリズム4ではない場合でも)。
- アプリケーションはWPFで記述されます(いいえ シルバーライト)。
- メインアプリケーションは非常に薄くなります。
- メインアプリケーションは、Webサービスを使用して、人がアクセスできる「アプリ/モジュール」のメニューを構築します。
- 「アプリ/モジュール」は、他の管理されたライブラリに完全に含まれます。
- メインアプリケーションは、これらのDLLを反映することにより、ビューとビューモデルを取得します。
- メインアプリケーションは、これらの「アプリ/モジュール」にログなどのサービスを提供する必要があります。
例えば:
基本的なユーザーには次のオプションがある場合があります。
- viewonlyアドレスレコード
すべての項目アドレス関連は、address.dll内にあります。
上級ユーザーには次のオプションがある場合があります。
- 新しいアドレスレコード
- オープンアドレスレコード(更新/削除)
- ユーザーを管理します
すべての項目アドレス関連は、address.dll内にあります。
関連するすべてのアイテムは、admin.dll内です。
アプリは実際にこれらのdllのいずれかを参照するべきではありません。100種類のモジュールが100個のモジュールがある場合、2つしかアクセスできない場合、そのうち2つだけがダウンロードされて使用されるように、それらに反映する予定です。一方、10人にアクセスできるユーザーは、それらの10を取得します。
WebServiceを介してダウンロードDLLをすでに解決しました。 :)
解決
「より良い」ものはありません。それらは異なるものです。
IMOあなたの選択は、要件によってのみ推進されるべきです。ここに投稿した要件に基づいて、MEFを使用することをお勧めします。なぜなら、DLLに含まれるモジュールがあり、メインアプリにはロードするモジュールを認識していないからです。これらのタスクは、MEFが存在する理由です。
とにかくあなたはそれらの両方を使用することができます:依存関係の注入の利点をとるためにモジュール性と統一のためのMEF(テスト可能性、再利用可能性、...)
他のヒント
すべてのモジュールがアプリと同時に再コンパイルされていない場合、MEFはメインアプリの変化するインターフェイスに対処する多くの方法を提供します。それ以外の場合はmef 五月 必要なよりも複雑になります。
私はプリズムで1年以上統一を使用してきましたが、いくつかの深刻な記憶の漏れの問題に気づきました。したがって、私はプリズム4とMEFに試してみることにしました。私がやったことは、まずアプリをPrism 4をUnityで使用するように変換することです。次に、MEFを使用するためにブランチを変換しました。面白そうに聞こえるかもしれませんが、MEFはメモリの消費を処理し、統一よりも何らかの形でリリースされているようです。
他の人が同じ経験をしたかどうかを聞いてうれしいでしょうか?
MEFとUnityがお互いにうまく機能できるかどうかのあなたの質問を考慮して、彼らがお互いに本当にうまく機能していることを伝えることができます。私は、プリズム、団結、MEFを使用した概念実証アプリケーションを開発しました。