Однажды я начал проект 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?
RelayCommand
реализацию (поскольку он «привязывается» напрямую к методам по соглашению, а не к свойствам ICommand).
RelayCommand
библиотеку из другой библиотеки, если та, которая используется Caliburn Micro, не работает для вас.
EventAggregator
для обмена сообщениями, а такжеNotificationObject
для ViewModelBase и MVVM LightRelayCommand
для команд. Важно определить, какие проблемы фреймворк собирается решить для вас, и использовать только эти решения. Не думайте, что вы вынуждены использовать всю библиотеку фреймворков.