3

私たちのアプリケーションには、PCL ライブラリ (RestSharp、Websocket4Net、Reactive Extensions など) としては利用できないいくつかの依存関係がありますが、ターゲットにする予定の各プラットフォームで利用できます。MvvmCross でこのシナリオを処理するための最良のアプローチは何ですか? 最も単純なものは何ですか？

4

2 に答える 2

2

これにはさまざまなアプローチ方法があります。

  • 問題が非常に大きい場合は、PCL アプローチを放棄して、複数のプラットフォーム固有のクラス ライブラリを使用できます。これらのライブラリは、MvvmCross PCL および RestSharp のプラットフォーム固有のバージョンなどを参照できます。これの長所と短所に関する議論については、「リンクとして追加」を使用する代わりにポータブル クラス ライブラリを使用する利点は何ですか?

    一般に、非常に大きなレガシー ライブラリを含める必要がある場合にのみ、このファイル リンク アプローチを採用するようになりました (たとえば、ある顧客は、3 つの別個の WCF サービスと通信する大きなビジネス ロジック ライブラリを持っていました...)。

  • あなたが言及したライブラリのいくつかは、すでに PCL ポートや代替手段を持っているかもしれません - 例えば

    現在、多くのオープン ソース作成者が PCL バージョンを提供しています。チェックしてください。

  • 多くの場合、ネイティブ ライブラリをインターフェイスの背後で抽象化して、実行時にそのライブラリの正しいバージョンを挿入できます。これは、プラグインが MvvmCross 内で行うことです

    https://github.com/slodge/MvvmCross/tree/v3/Plugins/で多くのプラグインがどのように構築されているかを確認できます

    このサンプルには非常に単純なプラグインがあります - https://github.com/slodge/MvvmCross-Tutorials/tree/master/GoodVibrations

  • 使用できる別のアプローチは、「参照アセンブリ」を提供することです。これらは、型とインターフェイスのシグネチャのみを含む PCL アセンブリです (つまり、NotImplementedException実装のみを提供します)。PCL プロジェクトはこれらのアセンブリにリンクし、UI プロジェクトは実際のアセンブリにリンクします。ビルド時に、PCL コアは署名に対してビルドされますが、MSBuild/XBuild は正しいネイティブ ライブラリが実際に取り込まれることを保証します。

    この最後の手法を実際に使用したことはありません。より良いアーキテクチャにつながるので、私はインターフェイス ルートを好みます。ただし、この手法は現在の MvvmCross Nuget パッケージで使用されているため、機能することがわかっています。

于 2013-05-14T07:27:56.573 に答える
1

テスターのダニエルは、このクラスの問題を解決する方法についてブログ投稿を書いています。

于 2013-05-14T04:02:14.847 に答える