Использование только частей выпуска сообщества мобильных блоков приложений для разработки WM 6.x

Question

Я нахожусь в процессе планирования архитектуры для распределенной системы бизнес-сферы, где много разных устройств разных типов должны поддерживаться в очень похожих сценариях использования.

Среди прочего мне нужно будет поддержать

• КПК на базе Windows Mobile 6.x
• Рабочие станции ПК

Эти приложения будут служить довольно простой бизнес-логикой, поэтому я не хочу использовать для этого раздутую архитектуру. Тем не менее, мне нужно поддержать:

• удаленные обновления
• сценарий в основном отключенный клиенты для КПК (и опционально, для ПК)

При поиске правильной эталонной архитектуры я наткнулся на выпуск сообщества мобильных блоков и расширение Mobile Contribute для этого выпуска. Что меня заинтересовало, так это:

• Отключенный агент и монитор подключений для поддержки сценария с отключенными клиентами
• Блок приложения Mobile Updater для поддержки обновлений

Я также знаю о аналоге SCSF для настольной платформы.

Теперь вот мои вопросы

1. По вашему опыту, является ли расширение MCSF для VS2008/WM6.x/.NET CF 3.5 достаточно зрелым и стабильным для производственного использования? Я не хочу быть жертвой осознания того, что он не очень подходит для использования в бизнесе, пока я нахожусь в середине проекта.
2. Поскольку приложение будет очень простым, я не хочу усложнять его с помощью шаблона MVP и других дополнений, связанных с CAB. Мне просто нужно поддержать сценарии, описанные выше. Можно ли будет использовать компоненты MCSF Community Release без необходимости проектировать все приложение в манере MCSF (с командами, внедрением зависимостей, MVP и т. Д.)? Я думаю, что я хочу быть простым для простого приложения.
3. То же самое для настольного ПК. Я также думаю, что переход на полную CAB/SCSF был бы серьезным излишним, поскольку это действительно очень простой набор функций, которые нужно реализовать, но я бы хотел сократить время разработки, используя средства обновления и, возможно, отключенные клиентские блоки. Просто без сложной части пользовательского интерфейса (я создам простые WinForms для пользовательского интерфейса). Было бы возможно?

Я также изучаю возможность совместного использования некоторого кода, связанного с отключенными клиентами / удаленными обновлениями, между ПК и КПК, но я не думаю, что это было бы возможно с MCSF/SCSF.

Я был бы признателен за совет от кого-то, кто шел по этому пути до меня:)

Answer 1

1. MCSF абсолютно ужасен. Похоже, что кто-то в Microsoft просто сказал разработчику с небольшим опытом взять SCSF и "заставить его работать" на Compact Framework. Это было переведено как "если это компилируется, тогда все в порядке", потому что это все, что, кажется, произошло.

   Это работает? Конечно, но святая медлительность, Бэтмен! Это совершенно непригодно для любого реального сценария. Достаточно плохо, что я написал замену с нуля, которая поддерживает (в основном) совместимость интерфейса и включает в себя только минимальный набор функций.

2. Я обнаружил, что если приложение содержит 2 или более просмотров, то стоит использовать шаблон MVP. В какой-то момент вам нужно добавить другое представление, и вы уже создали его. Кроме того, помещение ваших объектов в инфраструктуру DI/IoC часто обеспечивает такие вещи, как агрегация событий, что, на мой взгляд, очень полезно даже в приложениях без монитора, поэтому даже без использования MVP я в конечном итоге использую его.

3. Рабочий стол ничем не отличается в моей книге. Созданная мной библиотека IoC одинаково поддерживает как CF, так и FFx (а также MonoTouch и Phone 7), так как я делюсь большим количеством совместного использования кода на разных платформах. Редко я создаю настольный проект, где не использую его.

Теперь я не говорю, что вы должны использовать мой проект IoC. Я нахожу это полезным для всех проблем, с которыми я сталкиваюсь, и я знаю это достаточно хорошо, что, когда я сталкиваюсь с отсутствующей областью функциональности, я могу быстро добавить ее (хотя я не нашел много недостатков за месяцы). Если вам удобно или вы предпочитаете другую платформу DI/IoC, тогда отлично, используйте это. Я говорю: а) убегать от всего, что связано с MCSF, и б) использовать DI/IoC-фреймворк, даже если вы думаете, что приложение слишком простое, потому что нет такого понятия, как приложение реального мира. это слишком просто, чтобы извлечь из этого пользу.