一般的に....Mvvmcrossは実際には非常に軽いフレームワークになることを目指しています-プリズムよりもmvvmlightに近づくことを望んでいます...ビューとビューモデルにmvvmを使用できるようにすることを目的としています-次に、ビジネスをどのように記述するかロジック (ミデルとサービス) は本当にあなた次第です。
そうは言っても、私が書いたサンプルでは、一般的にIoCとプラグインを使用しています-それが「私の習慣」です-それが「ベストプラクティス」であるかどうかは間違いなく議論の余地があります:)
- 私が理解している限り、クロスプラットフォーム ビジネス ロジックは、RegisterServiceInstance 呼び出しを介して利用可能になるサービスに実装する必要があります。
はい、RegisterServiceInstance、RegisterServiceType、および GetService を組み合わせて、単純な IoC フレームワークを提供します。
私のアプリでは、通常、起動時にアプリが IoC に登録し、VM が必要なときに消費する「サービス」レイヤーにビジネス ロジックを実装することを選択します。
代わりに、ビジネス ロジックを vm 内で直接コーディングしたい場合、または (IoC の代わりに) サービスの直接コーディングを使用したい場合は、完全にそれを行うことができます。
- プラットフォーム固有の機能は、プラグインを介して公開されます。MvvmCross プラグインを使用するように努力する必要がありますが、必要な機能を提供するプラグインが見つからない場合は、自分で作成できます。カスタム プラグインの粒度はどのように計画すればよいですか? そこにビジネスロジックを持たないようにして、プラットフォーム固有のものだけを配置する必要がありますか? 標準の Mvvm プラグインを使用すると、アプリで大きなコード変更が必要になる場合でも、独自のプラグインを作成しないようにするためにこれを行う必要がありますか?それとも、プラグインの設計を自由に決定できますか?
はい、リベラルに！
プラグインは、PCL を使用して IoC を行うための正式な方法です。
mvx ツリーでは、プラグインは非常に小さく、ターゲットを絞っています。これは、プラグインが多くのプロジェクトで再利用できるように設計されているためです。
mvx ツリーでは、mvx は一般的であるため、プラグインにはビジネス ロジックが含まれていません。ビジネスについてはわかりません。
50 のインターフェイス実装を登録するアプリケーション用の単一のプラグインを作成する場合、その多くはビジネス オブジェクトです。「はい、そうしてください」 - ビジネス ニーズに合わせてコードを設計します。
最後に、プラグインはオプションであることに注意してください。プラットフォーム固有のコードがある場合は、それを vm に挿入する別の方法をいつでも見つけることができます。たとえば、ビューで実装を挿入したり、ファイルまたはアセンブリ リンクを使用する非 PCL コードを記述したりできます。各アプリ プラットフォームに適した実装を選択します。
- 最後に、いわゆるアプリケーション オブジェクトの目的、特にこの長い接尾辞 ("ApplicationObject") を使用する理由を完全には理解していません。アプリケーション オブジェクトとして認定されるものと、その名前を装飾することが推奨される理由
名前が完璧ではないことに同意しますが、もっと良い名前はまだ思いつきません。
MvxNotifyPropertyChanged オブジェクトは Ui スレッドを認識し、inpc 実装を提供します
MvxApplicationObject オブジェクトは MvxNotifyPropertyChanged から継承しますが、ナビゲート メソッドにもアクセスできます。
MvxViewModel オブジェクトは MvxApplicationObject から継承され、ビューで使用するように設計されています。
私が現在 MvxApplicationObject をよく使用する唯一の場所は、開始オブジェクト (アプリで最初のビューモデルを開始する「もの」) です。私は通常これを StartApplicationObject と呼んでいます。他の名前で呼びたい場合は、そうしてください - これが子猫に害を及ぼさないことを約束します.
補足: 最初の mvx プロジェクトでは、開始オブジェクトはもともと MvxViewModel から継承されていました...しかし、それはコード レビューで発見され、批判されました... ui アプリケーションで処理を行います - それは ..." - そして、MvxApplicationObject が誕生したのはその時です...
後で、ナビゲーションを要求する必要があるがビュー モデルではない他のオブジェクトがあることに気付いた場合、この基本クラスも役に立ちます。それ以外の場合は、使用する必要はありません...
要約すれば...
あなたの質問から、サンプルを読んで、私のアプリのコア部分を一般的にどのように構築するかをよく理解しているようです。
私が強調したい唯一のことは、柔軟性を維持することです。ベスト プラクティスは 1 つではないと思います。新しいプロジェクトのほとんどは、新しい独自の課題を提示します。通常、私はすべてのプロジェクトで新しいことを学び、試しています。
それが役立つことを願っています
スチュアート