30

Prism v4をダウンロードして、インストーラーを実行しました。ディレクトリに移動して、次の2つのバッチファイルを実行しました。

  • デスクトップのみ-MefQuickStart.batでモジュラリティを開く
  • デスクトップのみ-UnityQuickStart.batでモジュラリティを開く

これらのアプリケーションをコンパイルしても、実際の違いはわかりません。MEF vs Unityを検索し、いくつかの長所/短所を見つけましたが、Prismで使用することで「より良い」（そしてそれは主観的である）かどうかを具体的に示すものは何もありません。要件をリストすると、誰かが使用する正しいテクノロジーを教えてくれると思います（Prism 4でなくても）。

  • アプリケーションはWPF（Silverlightではない）で作成されます。
  • メインアプリケーションは非常に薄くなります。
  • メインアプリケーションは、Webサービスを使用して、ユーザーがアクセスできる「アプリ/モジュール」のメニューを作成します。
  • 「アプリ/モジュール」は、他の管理対象ライブラリに完全に含まれます。
  • メインアプリケーションは、これらのDLLに反映することにより、ビューとビューモデルを取得します。
  • メインアプリケーションは、これらの「アプリ/モジュール」にロギングなどのサービスをフィードする必要があります。

例えば：

基本ユーザーには、次のオプションがあります。

  • ViewOnlyアドレスレコード

アドレス関連のすべてのアイテムはAddress.dll内にあります。

上級ユーザーには、次のオプションがあります。

  • 新しい住所レコード
  • アドレスレコードを開く（更新/削除）
  • ユーザーを管理する

アドレス関連のすべてのアイテムはAddress.dll内にあります。
管理に関連するすべてのアイテムは、Admin.dll内にあります。

アプリは実際にはこれらのDLLのいずれかを参照するべきではありません。100の異なるモジュールがあり、ユーザーがそれらの2つにしかアクセスできない場合、そのうちの2つだけがダウンロードされて使用されるようにそれらに反映する予定です。一方、それらのうちの10にアクセスできるユーザーは、それらの10を取得します。

WebServiceを介したDLLのダウンロードはすでに解決しました。:)

4

4 に答える 4

21

「より良い」ものはありません。それらは異なるものです。

IMOの選択は、要件によってのみ決定されます。ここに投稿した要件に基づいて、MEFを使用することをお勧めします。これは、DLLにモジュールが含まれていて、メインアプリがロードするモジュールを認識していないためです。これらのタスクがMEFが存在する理由です。

とにかく、それらの両方を使用できます：モジュール性のためのMEFと依存性注入を利用するためのUnity（テスト可能性、再利用性、...）

于 2010-12-03T07:55:49.270 に答える
4

すべてのモジュールがアプリと同時に再コンパイルされない場合、MEFはメインアプリのインターフェースの変更に対処するための多くの方法を提供します。そうしないと、MEFが必要以上に複雑になる可能性があります。

于 2010-12-03T10:29:17.180 に答える
2

MEFとUNITYがうまく連携できるかどうかという質問については、お互いにうまく連携していると言えます。PRISM、Unity、MEFを使用した概念実証アプリケーションを開発しました。

于 2011-06-30T22:37:02.027 に答える
2

私はPRISMで1年以上Unityを使用していますが、いくつかの深刻なメモリリークの問題に気づきました。そこで、PRISM4とMEFを試してみることにしました。私がやったことは、最初にアプリをUnityでPRISM4を使用するように変換することです。次に、MEFを使用するようにブランチを変換しました。面白そうに聞こえるかもしれませんが、MEFはメモリ消費を処理し、Unityよりも何とかうまくリリースしているようです。

他の人が同じ経験をしたかどうか聞いてみたいですか？

于 2011-02-12T00:23:30.170 に答える