@Chizel

Здравствуйте! Изучаю потихоньку WPF с паттерном MVVM и прихожу к выводу, что надо уже брать какой то фреймворк и работать. Слышал про MVVMLight и Catel. Кто знаком с ними, можете кратко плюсы минусы каждого накидать? Буду очень благодарен.

0

@kotelok

Тот, который вам лично больше понравится. Для этого нужно взять наиболее популярные фреймворки (MVVMLight, Prism, Catel, Caliburn.Micro), реализовать с их использованием хотя бы самые простые примеры (биндинг свойств и команд, навигация по View) и решить какой вариант вам больше подходит.

Для меня, например, очень привлекательны идеи, реализованные в Caliburn.Micro, когда громоздкие однотипные куски кода ViewModel полностью уходят и заменяются на простые соглашения об именовании, когда байндинг выглядит непривычно, но зато более лаконичен. Однако, тут есть разные мнения, кто-то считает подобный подход неприемлимым в силу того, что появляется много неочевидного поведения (фреймворк многое сам додумывает и достраивает на этапе выполнения), кому-то специфичный синтксис байндинга не нравится. А по мне так, что угодно, только бы избавиться от всех этих DelegateCommand/RelayCommand и необходимости лицезреть этот жуткий оверхед при объявлении каждой команды.

1

@Topotun

Chizel, если тебе прям нужно совсем вкратце плюсы и минусы, то MVVMLight очень хорош для старта, потому что он позиционируется как легковесный фреймворк, на изучение которого нужно потратить минимум усилий. Catel - целая платформа, в которой есть всё) И кател хорошо изучать на реальном большом проекте, а не на проектах однодневках. Потому что маленькие проекты часто просто не смогут показать всю "мощь" фреймворка. Такая же история с Prism (это тоже огромный фреймворк).

А вообще, всё зависит от того, какие у тебя цели. Если ты хочешь выучить фреймворк с пользой, то начинай работать с самыми популярными фреймворками. В твоём случае - MVVMLight. Так же, я бы тебе посоветовал Caliburn или Caliburn.Micro. Но там порог вхождения уже выше, чем в MVVMLight. Так же, очень много инфы и очень много документации по MVVMLight. Куча примеров и большое сообщество. Поэтому для старта MVVMLight очень хороший вариант.

Ну и главное не забывать, что фреймворк - всего лишь инструмент. И зацикливаться на одном не нужно. Разные фреймворки предназначены для разных задач и для разных проектов. Поэтому пару месяцев кодь на MVVMLight, потом посмотри какой-нибудь другой фреймворк. Посмотришь, сравнишь, потом поймёшь к чему душа лежит

1

@Chizel

Большое спасибо за развернутые ответы. Про Caliburn.Micro вообще ничего не слышал, заинтересовало. Будем попробовать.

0

@madsen

Здравствуйте. Я за советом.
Самостоятельно занимаюсь изучением WPF (До этого также самостоятельно прошёл курсы по С# и EF). Признаюсь, из обучающего материала пока прочитал только небольшое руководство на Metanit.com.
Недавно получил тестовое задание от одной компании. Одним из требований является использование паттерна MVVM.
Выполнение этого задания меня вызывает определённые сложности. Например, первое с чем столкнулся - взаимодействие между окнами. В интернете есть какие-то решения, но они либо мне не очень понятны, либо не соответствую паттерну. К тому же, собирая по кусочкам информацию, не создаётся целостного понимания правильности разработки.
Соответственно, хочу узнать, применение фреймворков упрощает мне задачу? Насколько они нужны на раннем этапе и чем могут мне помочь? Как я понял из темы, для новичков лучше всего подходит MVVMLight. Есть ли какое-нибудь руководство на русском языке, как им пользоваться? И последнее, применение подобных Фреймворков даёт плюс или минус к тестовому заданию? Как компании относятся к ним?
Надеюсь, кто-нибудь ответит

0

@novikov.ea

Если приложение большое, то использование фреймворка будет решением, облегчающим разработку. Для малюсеньких приложений смысла использовать фреймворк нет.
Фреймворк может пригодиться тогда, когда известно, что приложение будет не уровня лабораторной работы, а несколько серьёзнее. Фреймворки могут помочь с разбиением приложения на модули, когда нужно уметь уже во время выполнения программы подгружать новые dll с функционалом. Фреймворк может заведовать функционалом открытия окон, распределением элементов интерфейса на окне, навигацией между элементами интерфейса и много чего ещё. Использование фреймворка может дать приложению гибкость и поддерживаемость. Если вы не используете какой-либо готовый фреймворк, то вы всё равно напишите некоторую часть его функционала самостоятельно.
Я использовал только PRISM. Правда, стоит признать, что на его изучение мне был выделен всего один день (тоже делал тестовое задание) и тогда я поломал голову несколько часов, прежде чем у меня все мысли встали на место, как надо правильно делать. Но разобраться реально. С другими фреймворками не работал. Думаю, что документации про каждый фреймворк в интернете достаточно. Можно попробовать посмотреть на примеры уже готовых приложений и оценить, какой вам больше нравится и более понятный.
Есть переведённые статьи про PRISM. Правда статья про уже устаревшую версию PRISM'а.
Читать и пробовать сделать
Я бы зачёл, как плюс. Минусом бы это было вряд ли.
Некоторые компании указывают в вакансиях, какой фреймворк они используют. Посмотрите, указан ли в вакансии какой-либо фреймворк, и, если указан, то используйте его.

Добавлено через 10 часов 42 минуты
Если что, то вот страничка PRISM на GitHub с актуальной информацией о нём. Там же есть ссылка и на примеры приложений.

4

@madsen

novikov.ea, большое спасибо за исчерпывающий ответ. "+" к репутации не получается поставить, пишет, что недостаточно прав

0

@novikov.ea

madsen, пожалуйста)

0

@skilllab

novikov.ea,
- используете ли вы многооконные приложения с передачей Модели по ним?
- используете ли вы одну ViewModel для представления в нескольких разных регионах или в разных окнах?
- используете ли вы модули?
- используете ли вы штатный ServiceLocator или какой то сторонний?
- используете ли вы MahApps?

Добавлено через 35 секунд
Всё это, естественно, при применении PRISM.

0

@novikov.ea

Многооконные приложения, конечно, реализую. Информацию между окнами, резумеется, тоже передаю
- Если произошло событие, то с помощью EventAggregator'а или подписки и обработки события экземпляра некоего класса, который создаётся при инициализации приложения и прокидывается в качестве зависимости ViewModel'ям
- Если информацию нужно передать при открытии окна, то просто можно задать эти значения в свойства ViewModel окна перед открытием этого окна
Наверное, если задача потребует, чтобы были две одинакое вьюхи, завязанные на одни и теже данные, то можно сделать так. Лично мне пока такая необходимость не встречалась.
Да. Продукт может иметь оболочку (приложение WPF) и отдельные проекты-модули. Модули можно использовать, например так:
- Пробная версия содержит 2 модуля, стадартная - 5 модулей, полная - 7 модулей
Или так:
- Один продукт загружает модули А, Б, В. Другой загружает А, Г, Д. Продукты типа разные, но у них есть общий функциональчик А. Можно комбинировать модули, чтобы создать прозвольное подмножество функционала для продукта.
ServiceLocator'ом не пользуюсь. Пользуюсь DI контейнером. Вообще не вижу задачи, которую бы нельзя было решить, не используя ServiceLocator. Единственное, где на мой взгляд ServiceLocator был бы удобен - это если требуется внедрить зависимоть в большое количество самописных вьюх. Так, например, делает Telerik для локализации контролов.
Видел, что MahApps существует. Но не познакомился ещё с ним)

0

@skilllab

А каким образом вы решаете строение проекта с многими окнами? В том смысле что:

- является ли ещё одно окно новым проектом в решении? Ибо на то новое окно существует своя логика, свои представления. Т.е. то новое окно в отдельной сборке того же решения.

- или новое окно является частью того же самого проекта?

- как быть если в проекте одно окно используется нескольким сборками? К примеру своё красивое окно ввода данных. Используется как для текущего проекта редактирования какой либо, ну к примеру базы данных, так и для проекта внесения новой записи. Т.е. одно окно на несколько проектов в решении.

- модули в PRISM - это просто регион в основном проекте, или же это может быть самостоятельная единица с собственными элементами управления и собственной MVVM. Как правильно его использовать?

0

@novikov.ea

Новое окно и ViewModel для обычно лежат в том же проекте
Я имею проект, на который ссылаются зависимые проекты-модули. Все общие штуки помещаю туда. Если у вас есть своё красивое окно ввода данных, то поместите его в общий проект и используйте его во всех модулях.
Модуль можеть регистрировать нужные ему зависимости в DI контейнере для своих объектов, регистрировать ViewModel и View. Модуль может регистрировать вьюхи в регионах, определённых в оболочке (проекте WPF), для того, чтобы отобразить свои элементы интерфейса на нём. Например, в каком-нибудь ItemsControl'е можно списочком отобразить кнопочки для каждого подгруженного модуля, и по нажатию на кнопку, отображать на главном экране UI для этого модуля.
Получается, что оболочка не знает ни о каких модулях. А модуль сам для себя отобразил кнопку в нужном месте (считается, что он знает, как называется регион). Оболочка просто предоставила регион для этого.

0

@skilllab

Ну и пока крайний вопрос)) почему Модуль? Когда это просто ещё один проект в решении. Чем в PRISM Модуль отличается от
ещё одной обычной сборки? Или это просто семантика.

0

@novikov.ea

У PRISM есть специальная функция, которая загружает проекты-модули. ModuleInitializer или какая-то типа такая пурга....
Он ищет в сборке классб который реализует интерфейс IModule и вызывает у него метод Initialize. Можно ещё получить событие, что модуль загрузился и отобразить сообщение на экран. И возможно, что-то ещё....
Вы можете написать и свою реализацию, если хочется. Но в PRISM это уже всё сделано за вас. Смысл такой)

1