Как выбрать НЕ использовать фреймворк (Caliburn.Micro и т. Д.) В данном приложении MVVM?

28

Однажды я начал проект MVVM / WPF, который в конечном итоге был построен и развернут, и для этого я много изучал Caliburn.Micro MVVM Framework. Факт: Я в конечном итоге не используя Caliburn.Micro для этого, и в конечном итоге реализации некоторых MVVM понятий , сам ( в частности, только ViewModelBaseи RoutedCommandклассы).

Теперь я был назначен на несколько более крупный проект в том же духе: «Однопользовательское приложение для многопользовательского автономного рабочего стола», так сказать, и решил использовать Caliburn.Micro. И вот тут начинается моя «проблема».

Я прочитал в этом знаменитом сообщении в блоге , заголовок которого гласит: «Если вы используете MVVM, то вам нужна платформа», что:

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

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

Я бы согласился с первым чтением, но мой реальный опыт применения Caliburn.Micro (CM) в моем настоящем приложении заключается в невежестве и дезориентации. То есть структура не облегчала процесс, а наоборот. Чтение постоянно повторяющихся примеров, представленных Робом Айзенбергом в довольно (слишком) неофициальной документации, и попытка вывести модели использования из замысловатых предоставленных примеров и их совершенно непрямых отношений класса и интерфейса, где вещи, как кажется, предназначены для работы на основе Побочные эффекты, кажется, по-человечески невозможны, если вы не опытный гений (извините за напыщенную речь, но я думаю, вы понимаете, о чем я).

Не говоря уже о том, что любой вышеперечисленный сценарий, похоже, включает в себя контейнеры IoC, с которыми я никогда не работал, и которые, кажется, решают проблему, которой у меня может даже не быть . Мне не хочется тратить больше времени на изучение этих вещей, а не думать о своих проблемах и областях применения. Я просто хотел банан, но КМ дал мне гориллу (IoC) с корзиной бананов.

Теперь, когда я собираюсь вернуться к своей доморощенной MVVM-среде, состоящей только из нескольких специфичных для MVVM классов, которые я на самом деле хочу реализовать, я хотел бы, по крайней мере, дать CM шанс, если я что-то здесь потеряю, или просто делать вещи "неправильным путем" из чистой неопытности и невежества. И вот вопрос:

Широко распространено мнение, что «фреймворки делают вещи проще и естественнее», но если мне случается испытывать совершенно противоположное, значит ли это, что я не должен использовать фреймворк или что я пытаюсь научиться этому неправильно? Есть ли подсказка, что я вообще не должен использовать фреймворк? Или есть какой-то "правильный" способ выяснить, как использовать CM для простой разработки MVVM?

frameworks wpf mvvm heltonbiker
источник
1
Лично я выбираю элементы из каждой среды, чтобы использовать их для определенного поведения, а остальное игнорирую. Например, мне нравится использовать Microsoft PRISM EventAggregatorдля обмена сообщениями, а также NotificationObjectдля ViewModelBase и MVVM Light RelayCommandдля команд. Важно определить, какие проблемы фреймворк собирается решить для вас, и использовать только эти решения. Не думайте, что вы вынуждены использовать всю библиотеку фреймворков.
Рейчел
@Rachel Я планировал использовать этот подход с Caliburn.Micro, но не смог найти RelayCommandреализацию (поскольку он «привязывается» напрямую к методам по соглашению, а не к свойствам ICommand).
Хелтонбайкер
Я никогда не использовал фреймворк Caliburn, потому что мне не нравилось, насколько тесно он связывает виды с слоем Model / ViewModel. В вашем случае я не вижу причин, по которым вы не могли бы использовать RelayCommandбиблиотеку из другой библиотеки, если та, которая используется Caliburn Micro, не работает для вас.
Рэйчел
@Рэйчел о том, «насколько близко [caliburn] связывает вид со слоем MVM», что именно вы имеете в виду? Каков был бы «некалиброванный» способ связать эти слои лучшим, более MVVM способом? (Я искренне спрашиваю, потому что я в настоящее время не знаю).
Хелтонбайкер
Честно говоря, я никогда не использовал Caliburn Micro, поэтому я чувствую, что плохо разбираюсь в этом. Я помню, что у меня сложилось впечатление, что View был создан первым и отвечал за решение объектов code-behind, что мне не понравилось, так как мне не нравилась разработка View-First. Другой была автоматическая привязка, которая основывалась на том, как вы называете компоненты XAML, так как я думал, что это слишком сильно привязало пользовательский интерфейс к бизнес-уровню. Я слышал хорошие вещи о фреймворке, и не рекомендую избегать этого только по моему мнению. Попробуйте сами и посмотрите, нравится ли вам это :)
Рэйчел

Ответы:

16

Я пробовал CaliburnMicro и MVVMLight, и при использовании Caliburn я действительно чувствую то, что вы чувствуете, уверен, что это действительно волшебная возможность привязать управление к свойству, просто используя Name = "PropertyName" вместо старого Text = "{Bind PropertyName}", но в конец Caliburn делает все возможное, чтобы сделать эту волшебную вещь, когда что-то идет не так, как надо, отлаживать очень сложно, что еще хуже, у них есть много способов сделать что-то одно.

Но при использовании MVVMLight он тонкий, когда вы его используете, вы, вероятно, понимаете, что он почти на 100% похож на ваш MVVM Framework, и в нем есть некоторые функции.

Я знаю, что это не отвечает на ваш вопрос «Как НЕ использовать фреймворк», но, честно говоря, я не могу рекомендовать вам идти по этому пути, потому что это просто неправильно, я также думаю, что вы просто потерялись, потому что вы используете полнофункциональный фреймворк вместо использования простого один первый.

Кирие
источник
Тогда вы думаете, что я должен, по крайней мере, попытаться использовать MVVMLight в качестве некоторого рода "лекарства" от "Caliburn.Micro дезориентация"? Я бы наверняка посмотрел, если это так.
Хелтонбайкер
@heltonbiker Определенно, попробуй. Это гораздо проще, по крайней мере, дать вам хорошую опору на MVVM Framework.
Кири
Я согласен, что происходит слишком много магии. Исходя из переменного и монтажного фона я предполагаю. E-то не сработает, только обнаружив, что это происходит из-за магии на заднем плане. Невозможно отладить, и когда у вас часто возникают проблемы с производительностью, вы не можете с этим легко справиться.
Ролл
10

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

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

Майкл
источник
2
Кроме того, MVVM, предлагаемый Microsoft (из коробки, WPF), очень не хватает. Очень расстраивает даже программистов, которые считают себя (и это правильно) опытными разработчиками. Волшебные строки, непонятные исключения во время выполнения, самые простые вещи, такие как привязка группы радиокнопок к перечислению, выглядят как stackoverflow.com/q/397556/168719 - что могут делать фреймворки? Они должны либо повторить этот уровень сложности, либо попытаться обеспечить действительно толстую абстракцию над ним
Конрад Моравский
2
@KonradMorawski WPF сам по себе не является MVVM; Вы можете сделать код с WPF, но это не MVVM. Поэтому, если вы хотите использовать WPF и MVVM, вам нужно использовать инфраструктуру MVVM или реализовать ее самостоятельно.
Энди
1
@ Конечно, но можно с уверенностью сказать, что WPF предназначен для MMVM. Я имею в виду функциональность MVVM, которая встроена в WPF. Я знаю, что вы все еще можете сделать код позади
Конрад Моравский
@KonradMorawski Вы можете использовать WPF с MVVM, и они сконструировали его с учетом этой возможности, но в WPF нет встроенных функций, специфичных для MVVM. Точно так же, как вы можете использовать MVP с WinForms, но WinForms не предлагает ничего специально для использования этого шаблона, это ваше дело.
Энди
3
@ А может, сейчас мы спорим о определениях. Я имею в виду, что весь «клей», который делает возможным MVVM, уже есть - привязки данных в XAML и DataContextт. Д.
Конрад Моравский,
7

Мой первый опыт работы с WPF был с использованием Caliburn.Micro, так что это, вероятно, сильно отличается от большинства разработчиков. Я обнаружил, что и WPF, и Caliburn.Micro - довольно крутая кривая обучения, пришедшая из WinForms, однако после некоторого опыта работы с обоими я нашел, что их приятно использовать в паре. В настоящее время работаю в другой организации, где Caliburn.Micro не используется, я обнаружил, что существует ОЧЕНЬ много дублирующего кода, что делает кодовую базу довольно раздутой и излишне сложной.

Я определенно согласен с тем, что в Caliburn.Micro есть некоторые ошибки, которые могут усложнить отладку, однако, как только они появятся, они вряд ли снова станут испытывать боль. Увеличенная скорость разработки, более чистый и компактный код и общая структура, способствующая улучшению MVVM, более чем оправданы.

Caliburn.Micro также не делает недействительным стандартный WPF - он просто строится поверх него, что означает, что вы все равно можете использовать функции WPF, если хотите, и использовать Caliburn для нескольких кусочков, если хотите. Это похоже на то, как TypeScript и JavaScript сосуществуют в моем сознании.

Я бы определенно использовал Caliburn.Micro в любом новом проекте WPF, над которым я работаю в будущем, если бы у меня была такая возможность.

Росс
источник
3
Спасибо за Ваш ответ. Два года спустя я понял, что гораздо легче «принять» эти фреймворки после понимания концепции контейнеров внедрения зависимостей, которую я узнал из превосходной книги Марка Сиемана «DI in .NET».
Хелтонбайкер
1

Для тех, кто прибывает сюда из-за разочарования в Caliburn.Micro, взгляните на эту структуру: Stylet

Он вдохновлен Caliburn.Micro, за исключением того, что удаляет много магии, которая оставляет вас дезориентированными о том, что происходит. Кроме того, документация написана на гораздо более простом языке, не предполагая, что вы хотите разбираться в техническом жаргоне. Гораздо лучше для начинающих.

Кроме того, Stylet использует подход ViewModel-First. Caliburn.Micro и многие другие фреймворки используют подход View-First, что связано с некоторыми неловкими проблемами. Если вы уже очень хорошо разбираетесь в принципах SOLID и шаблонном коде, вы, вероятно, найдете подход ViewModel-First более естественным, поскольку он предполагает, что ваша логика должна управлять системой, а не представлением.

JamesHoux
источник