MVVM, Unity, Prism, MEF, Caliburn - Что я должен использовать?

Пожалуйста, помогите - я заблудился!

Я пишу небольшое настольное приложение, которое имеет некоторые элементы управления и некоторый экран. Впоследствии это должно быть интегрировано с небольшим веб-сайтом, также имеющим несколько экранов. Идея состоит в том, чтобы позволить пользователю редактировать видео и выбирать изображения, а затем делиться своими результатами со своими друзьями.

Настольное приложение использует С# WPF, веб-сайт - ASP.Net MVC.

Я читал, что увеличение использования приложения за несколькими экранами было бы проще с использованием MVVM. Поэтому я начал поиск и обнаружил Caliburn.Micro и MVVM.Light. Я загрузил несколько учебников, но, так же как я собирался глубоко погрузиться в материал, я нашел здесь на S.O. что там также Prism, MEF, Unity, ReactiveUI - Это становится слишком много!

Мне страшно учиться новым вещам - мне нужны годы для изучения WPF и ASP.Net MVC. Я не хочу изучать много нового материала, чтобы узнать позже, что это не актуально. И у меня нет архитектора, чтобы наставлять меня.

Итак, мой вопрос: Не могли бы вы перенести эти фреймворки и технологии в перспективу и предложить мне сосредоточиться на изучении и использовании (например, что может быть позже использовано в Windows 8)?

Ответ 1

Если вы хотите создать приложение MVVM (которое вы, вероятно, делаете для различных преимуществ), вам нужна структура MVVM.

Я бы порекомендовал Caliburn.Micro, так как это просто реализовать по примерам на странице документации Caliburn.Micro. Он также имеет очень убедительное соглашение по механизму конфигурации и использует систему Actions для вызова глаголов (методов) на ваших моделях просмотра из представления, Это более мощно, чем любой другой механизм, который я видел.

Prism - это довольно тяжелая структура, которая включает элементы дизайна MVVM, которые помогают реализовать, а также специально адаптированы для создания составных приложений (приложений, которые созданы из развязанных компонентов внутри оболочки хоста).

MEF полезен для этих типов приложений, которые должны обнаружить плагины или расширения для приложения (даже после того, как приложение загрузилось), и могут использоваться вместе с инфраструктурой MVVM, такой как Caliburn.Micro. MEF также может использоваться для реализации инверсии управления, но не предоставляет некоторые основные функции, обнаруженные при другой инверсии управляющих контейнеров, поэтому вы можете использовать его только для реализации функциональных возможностей плагина.

Unity является контейнером IoC и будет использоваться для реализации инъекции зависимостей для вашей общей инфраструктуры приложения. Есть много контейнеров IoC на пространстве .NET, хотя некоторые из них предлагают либо улучшенную производительность, либо дополнительные функции, либо более дружественный API.

Я не знаю о ReactiveUI, поскольку я его не использовал.

Если вы говорите о максимизации повторного использования кода для перехода на WinRT, MVVM - отличный выбор.

Ответ 2

PRISM уже включает логику MEF и MVVM:)

Здесь немного объяснений:

MVVM стоит для логики в вашем приложении. Фактически умный способ развязки View, View-Model и Model. Не знаю никакой лучшей (?) Рамки для этого - вы можете проверить Catel, если хотите, или MVVM Light, но это всего лишь тонна кода от кого-то, кто понимает логику MVVM и просто упрощает ее реализацию. Вы могли бы попытаться написать свою собственную инфраструктуру MVVM и увидеть, что "нет секретного ингредиента" - точно такой же повторяющийся код и те же классы и т.д. На самом деле вам не нужна любая структура MVVM для реализовать MVVM.

Как только вы узнаете и напишите MVVM, вы сразу станете предметом сомнений - как я NUnit тестирую его развязкой (это, например, нетривиальная проблема в Silverlight) - вот здесь все функции IOC/Inject входят в игру. Например, MEF. Рассмотрим следующий пример, чтобы понять общую картину об Inject framework:

Проект "Общий", написанный в "наименьшем разделителе" (например, Portable Library)

    public interface IAmSharedInterface
    {
        string SayHello();
    }

Проект "Основной", ссылка только на проект "Общий"

    public class IAmMainClass
    {
        [ImportingConstructor]
        public IAmMainClass(IAmSharedInterface SharedInterface)
        {
             SharedInterface.SayHello();
         }
    }

Project 'Implementor', ссылается только на проект 'Shared'

   [Export(IAmSharedInterface)]
   public class IAmImplementor: IAmSharedInterface
   {
       public string SayHello()
       {
          return "Hello from implementator class to whoever using it";
       }
    }

Вы видите - нет прямой ссылки между проектами "Main" и "Implementator" - все "магия" происходит в процессе сборки/разрешения MEF/Unity. Таким образом, вы можете легко запустить NUnit test на Main без использования проекта "Исполнитель" и "Реализация" с "Основным". Там также сценарий, в котором другой проект может реализовывать и экспортировать "IAmSharedInterface" специально для целей тестирования.

Итак, вернемся к ПРИЗМЕ - у него есть все (!) это. Я знаю, что он не может легко понять не просто, и не подходит для простых программ Hello World, но как только вы узнаете об этом - пути назад нет. Он просто склеивает все части вместе и дает вам большую степень свободы в использовании любой структуры moq, которую вы хотите (например, Rhino).

Призма, развивающаяся в Microsoft, поэтому (надеюсь) будет поддерживаться не только в Windows 8, но и в Windows 9 и во всех будущих версиях.

Независимо от того, что вы просили все это: MVVM, Inject, decouple/plug-ins, легко читается и тестируется

Ответ 3

Чтобы сохранить добавление к подробной информации выше, я попытаюсь сделать жизнь легкой для вас.

1) Теперь забудьте о архитектуре IOC/Dependency Injection/Plugin. Вы говорите, что создаете простое приложение, поэтому забудьте об этом пока. Держите ваш код в порядке, и вы можете реализовать это позже, если это необходимо (это хороший материал).

2) Из представленных вами структур я бы предложил Caliburn.Micro. Это относительно прямолинейно и легко. Это не займет много времени, чтобы встать и работать.

3) Создайте свою модель в отдельной сборке, которую вы можете использовать как для своего приложения Windows, так и для вашего веб-сайта MVC.

Держите его простым и не увяжитесь со всеми технологиями.