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

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

Если вы говорите о максимизации повторного использования кода для перехода на WinRT, то MVVM is a great choice.

Answer 2

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

Ok немного объяснения здесь:

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

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

проекта «общей», написанной в «наименее разделителем» (например, портативный библиотеки)

public interface IAmSharedInterface 
    { 
     string SayHello(); 
    } 

Проект «Main», только ссылка «Общий» проект

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

проект 'Implementor' ссылка только 'Общий' проект

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

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

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

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

Что бы вы спросили, что это все внутри: MVVM, Инъекция, отвязать/плагинов, легко читать и тест

Answer 3

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

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

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

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

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