En utilisant uniquement les parties de la communauté mobile blocs d'application de sortie pour le développement de WM

Question

Je suis en train de planifier une architecture pour une ligne de système distribué d'affaires, où de nombreux dispositifs différents de différents types doivent être pris en charge dans un des scénarios de cas d'utilisation très similaires.

Entre autres, je devrai le soutien

• Windows Mobile 6.x les PDA
• postes de travail PC

Ces applications serviront assez simple logique métier, donc je ne veux pas utiliser l'architecture surfaite pour elle. , Je dois encore le soutien:

• des mises à jour à distance
• la plupart des clients déconnectés scénario pour les PDA (et le cas échéant, pour le PC)

Alors que la recherche de l'architecture de référence appropriée, je suis tombé sur mobile Communauté blocs d'application et mobile Contribuer l'extension à cette version. Ce qui m'a intéressé a été maintenu:

• Disconnected Agent et moniteur de connexion pour soutenir le scénario de clients la plupart du temps déconnecté
• Updater mobile Application Block à des mises à jour de support

Je suis également conscient de la contrepartie SCSF pour la plate-forme de bureau .

Maintenant, voici mes questions

1. est, dans votre expérience, extension MCSF à VS2008 / WM6.x / CF .NET 3.5 assez stable et mature pour l'utilisation de la production? Je ne wan't être victime de savoir, qu'il n'est pas vraiment adapté à un usage professionnel, alors que je suis au milieu du projet.
2. Étant donné que l'application sera très facile, je ne veux pas faire trop compliqué avec le motif de MVP et d'autres ajouts cadres connexes CAB. J'ai juste besoin de soutenir les scénarios décrits ci-dessus. Serait-il possible d'utiliser des composants MCSF Communauté de sortie sans avoir à l'architecte toute l'application de la manière MCSF (avec des commandes, l'injection de dépendance, MVP, etc.)? Je pense que je vais vouloir le garder simple pour la simple application.
3. Même chose pour le bureau App PC. Je pense aussi que d'aller pour plein CAB / SCSF serait une surpuissance importante ici, car cela est vraiment un ensemble très simple de fonctionnalités à mettre en œuvre, mais je voudrais réduire le temps de développement en utilisant Updater et éventuellement le déconnecté blocs clients. Juste sans la partie de l'interface utilisateur compliquée (je vais créer WinForms simples pour l'interface utilisateur). Serait-il possible?

Je mène également des recherches la possibilité de partager une partie du code lié à des clients déconnectés / mises à jour à distance entre le PC et PDA, mais je ne pense pas que cela soit possible avec MCSF / SCSF.

J'apprécierait un conseil de quelqu'un qui est descendu cette route devant moi:)

Answer 1

1. MCSF is absolutely horrible. It appears that someone in Microsoft simply told a developer with little experience to take the SCSF and "make it work" on the Compact Framework. That was translated as "if it compiles, then it's fine" because that's all that appears to have happened.

   Does it run? Sure, but holy slowness Batman! It's completely unusable in any real-world scenario. It's bad enough that I wrote a replacement from the ground up that maintains (mostly) interface compatability and includes only a minimal set of features.

2. I've found that if an app contains 2 views or more, then it's worth using the MVP pattern. At some point you'll need to add another view and you'll have already architected for it. Also, putting your objects into a DI/IoC framework often enables things like event aggregation, which I find terribly useful even in headless applications, so even without any MVP goo I end up using it.

3. The desktop is no different in my book. The IoC library I created supports both the CF and FFx identically (as well as MonoTouch and Phone 7) as I do a lot of code sharing across platforms. It's rare that I create a desktop project where I don't use it.

Now I'm not saying that you have to use my IoC project. I find it useful for all the problems I hit, and I know it well enough that when I hit a missing area of functionality, I can quickly add it (though I've not found much lacking in months). If you're comfortable or prefer another DI/IoC framework, then great, use that. What I am saying is a) run screaming away from anything that has to do with MCSF and b) use a DI/IoC framework, even if you think the app is too simple for one becasue there's no such thing as a real-world app that is too simple to benefit from it.