Services, plugins et objets d'application MvvmCross

Question

Je considère utiliser MvvmCross pour porter mon application sur plusieurs plates-formes. J'ai vérifié quelques projets qui utilisent MvvmCross, et le cadre semble très prometteur et facile à adopter. Je voudrais clarifier quelques concepts pour m'assurer que je ferai le bon portage.

1. Pour autant que je compris, la logique métier cross-platform devrait être mis en œuvre dans les services qui deviennent disponibles par RegisterServiceInstance appels.

2. La fonctionnalité spécifique à la plate-forme est exposée via des plugins. Je devrais essayer en utilisant MvvmCross plugins mais si je ne trouve pas celui qui offre des fonctionnalités dont j'ai besoin je peux écrire le mien. Comment dois-je planifier la granularité des plugins personnalisés? Devrais-je éviter d'avoir une logique métier et ne mettre que des choses spécifiques à la plate-forme? Si l'utilisation du plugin standard Mvvm nécessite de gros changements de code dans mon application, devrais-je encore le faire pour éviter de faire mes propres plugins ou je peux être libéral dans la décision de conception de plugin?

3. Enfin, je n'ai pas complètement compris le but des soi-disant objets d'application, en particulier pourquoi ils utilisent ce post long ("ApplicationObject"). Qu'est-ce qui est qualifié d'objet applicatif et pourquoi est-il recommandé de décorer son nom?

Merci d'avance.

Answer 1

Généralement .... Mvvmcross vise en fait à être un framework assez léger - il espère être plus proche de mvvmlight que de prisme ... Son but est de vous permettre d'utiliser mvvm pour voir et voir des modèles - alors comment vous écrivez votre logique d'affaires (midels et services) est vraiment à vous.

Cela dit, pour les échantillons que j'ai écrit, je ne l'utilise généralement IoC et plugins - de sorte que est « ma pratique » - si c'est la « meilleure pratique » est certainement discutable :)

1. Pour autant que je comprenne, la logique métier multiplateforme doit être implémentée dans les services qui deviennent disponibles via les appels RegisterServiceInstance.

Oui, RegisterServiceInstance, RegisterServiceType et GetService fournissent ensemble un cadre simple IoC. Dans mes applications, je choisis généralement d'implémenter une logique métier dans une couche de service que l'application enregistre avec IoC au démarrage et que les VM consomment quand ils en ont besoin.

Si vous vouliez coder directement votre logique métier dans les vm ou si vous vouliez utiliser le codage direct des services (au lieu de l'IoC), vous êtes parfaitement capable de le faire.

1. fonctionnalités spécifiques à la plate-forme est exposée par l'intermédiaire de modules externes. Je devrais essayer d'utiliser les plugins MvvmCross mais si je ne trouve pas celui qui offre des fonctionnalités dont j'ai besoin, je peux écrire le mien. Comment dois-je planifier la granularité des plugins personnalisés? Devrais-je éviter d'avoir une logique métier et ne mettre que des choses spécifiques à la plate-forme? Si l'utilisation du plugin Mvvm standard nécessite de gros changements de code dans mon application, devrais-je encore le faire pour éviter de faire mes propres plugins ou je peux être libéral dans la décision de conception de plugin?

Oui, soyez libéral!

Les plugins ne sont qu'une façon formelle de faire de l'IoC en utilisant des PCL.

Dans l'arborescence mvx, les plugins sont très petits et ciblés car ils sont conçus pour être réutilisés dans de nombreux projets.

Dans l'arborescence mvx, les plugins ne contiennent pas de logique métier car mvx est général, il ne connaît pas votre activité. Si vous voulez écrire un seul plugin pour votre application, qui enregistre 50 implémentations d'interface, dont beaucoup sont des objets métier, alors "oui, s'il vous plaît faire" - archivez votre code autour des besoins de votre entreprise. Enfin, veuillez noter que les plugins sont facultatifs - si vous avez un code spécifique à la plate-forme, vous pouvez toujours trouver un autre moyen de l'injecter dans votre vm's - par ex. vos vues peuvent injecter des implémentations ou vous pouvez écrire du code non-PCL qui utilise un lien de fichier ou d'assemblage pour sélectionner la bonne implémentation pour chaque plate-forme d'application.

1. Enfin je n'ai pas entièrement compris le but de ce qu'on appelle des objets d'application, en particulier pourquoi ils utilisent cette longue Postfix (« applicationObject »). Ce qui est qualifié comme un objet applciation et pourquoi il est recommandé de décorer son nom

Je suis d'accord le nom n'est pas parfait - mais je ne peux toujours pas penser à un meilleur.

objets MvxNotifyPropertyChanged connaissent le fil Ui et fournir une implémentation de INPC

objets MvxApplicationObject hériter de MvxNotifyPropertyChanged mais ont également accès à naviguer méthodes.

Les objets MvxViewModel héritent de MvxApplicationObject et sont conçus pour être utilisés avec des vues. Le seul endroit où j'utilise couramment MvxApplicationObject est pour l'objet de départ - le "truc" qui lance le tout premier viewmodel dans l'application. J'appelle communément le StartApplicationObject parce que cela décrit ce que c'est. Si vous voulez l'appeler quelque chose d'autre, alors s'il vous plaît faites - je vous promets que cela ne causera aucun dommage à tous les chatons.

remarque: dans le tout premier projet de mvx, l'objet de départ à l'origine héritée de MvxViewModel ... Mais qui a été pris et a critiqué à la révision du code ... « ce n'est pas vraiment un viewmodel - il est plus d'un - thingy - vous savez - il fait des choses dans l'application ui - c'est un ... "- et c'est là que MvxApplicationObject est né ...

Si vous trouvez plus tard que vous avez d'autres objets qui ont besoin de demander la navigation, mais qui sont aren Ne regardez pas les modèles, alors cette classe de base est aussi pour vous. Sinon, ne vous sentez pas obligé de l'utiliser ...

---

En résumé ...

De votre question, il semble que vous avez lu les échantillons et une bonne compréhension pour comment je construis généralement la partie centrale de mes applications.La seule chose que je soulignerais, c'est que je reste flexible - je ne crois pas qu'il y ait une meilleure pratique, la plupart des nouveaux projets présentent de nouveaux défis uniques et j'apprends et j'essaie généralement de nouvelles choses sur chaque projet.

espoir qui aide

Stuart