Using only parts of Mobile Application Blocks Community Release for WM 6.x development

Question

I am in a process of planning an architecture for a line of business distributed system, where many different devices of different types must be supported in a very similar use cases scenarios.

Among others, I will need to support

• Windows Mobile 6.x based PDAs
• PC workstations

Those apps will serve pretty simple business logic, so I do not want to use overblown architecture for it. Yet, I need to support:

• remote updates
• mostly disconnected clients scenario for PDAs (and optionally, for the PC)

While researching for the proper reference architecture, I stumbled upon Mobile Application Blocks Community Release and Mobile Contribute extension to that release. What kept me interested has been:

• Disconnected Agent and Connection Monitor to support the mostly disconnected clients scenario
• Mobile Updater Application Block to support updates

I am also aware of the SCSF counterpart for the desktop platform.

Now, here are my questions

1. Is, in your experience, MCSF extension to VS2008/WM6.x/.NET CF 3.5 mature and stable enough for the production use? I don't wan't to be a victim of knowing, that it is not really suitable for business use, while I am in the middle of the project.
2. Since the application will be very easy, I do not want to make it overly complicated with the MVP pattern and other CAB related framework additions. I just need to support the scenarios described above. Would it be possible to use MCSF Community Release components without having to architect the whole application in the MCSF manner (with commands, dependency injection, MVP etc.)? I think I will want to keep it simple for the simple application.
3. Same for the desktop PC App. I also think, that going for full CAB/SCSF would be a major overkill here, as this is really a very simple set of features to be implemented, yet I would like to cut down on development time by utilizing the updater and possibly the disconnected client blocks. Just without the complicated UI part (I will create plain WinForms for the UI). Would it be possible?

I am also researching the possibility to share some of the code related to disconnected clients/remote updates between the PC and PDA, but I don't think that would be possible with MCSF/SCSF.

I would appreciate an advice from someone who went down that road before me :)

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.