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

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

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

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

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

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

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


person Avi    schedule 29.05.2012    source источник


Ответы (4)


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

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

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

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

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

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

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

person devdigital    schedule 29.05.2012

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

Хорошо, небольшое объяснение здесь:

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

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

Проект 'Shared', записанный через 'наименьший разделитель' (например, Portable Library)

    public interface IAmSharedInterface
    {
        string SayHello();
    }

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

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

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

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

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

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

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

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

person Jasper    schedule 31.05.2012

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

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

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

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

Будьте проще и не увязните со всеми технологиями.

person pfeds    schedule 02.07.2012
comment
Я пытался это сделать, но туториалы Caliburn.Micro START с инверсией управления и MEF! (например, buksbaum.us/2010/08/04/caliburn-micro -the-meftacluar) :( - person Avi; 02.07.2012
comment
Учебники начинаются с IOC / MEF и т. Д., Потому что в большинстве производственных приложений это будет фундаментальной частью архитектуры. Однако в вашем случае вы создаете небольшое приложение, и я полагаю, вы единственный разработчик? - person pfeds; 04.07.2012

В этом ответе воспроизводятся некоторые сокращенные фрагменты блога Rockford Lhotka. статья «Для использования шаблона MVVM требуется фреймворк», на которую ссылались в другом ответе.

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

Есть три довольно популярных шаблона проектирования уровня представления, которые я в совокупности называю шаблонами «M»: MVC, MVP и MVVM. Это потому, что все они имеют букву «M», означающую «Модель», а также некоторые другие конструкции.

Суть всех этих шаблонов «M» в том, что для типичных разработчиков шаблоны бесполезны без фреймворка. Использование шаблонов без фреймворка почти всегда приводит к путанице, сложностям, высоким затратам, разочарованию и, в конечном итоге, к отчаянию.

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

...

Попытка сделать что-то вроде MVVM без фреймворка - это огромная работа. Тонны повторяющегося кода, изобретение велосипеда и переобучение людей мыслить по-другому.

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

Вы можете спросить себя, почему шаблон MVC стал популярным в ASP.NET всего несколько лет назад ...

Как ни странно, MVC только начал становиться мейнстримом в мире Microsoft, когда появился ASP.NET MVC. Это комплексная платформа с инструментами, интегрированными в Visual Studio. Как результат. типичные разработчики могут просто создавать модели, представления и контроллеры. До этого им также приходилось создавать все, что делает фреймворк MVC, а это большой объем кода. И не только много кода, но и код, который не имеет абсолютно никакого отношения к бизнес-ценности, а относится только к реализации самого шаблона.

...

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

...

Между тем, Caliburn Micro, по-видимому, является лучшей средой MVVM - безусловно, наиболее широко используется [по состоянию на 2012 год] ...

(Текст скопирован в строку для сохранения.)

person StayOnTarget    schedule 20.08.2018