Значение MVVM в бизнес-приложениях (и современные методы разработки)

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

Тем не менее, моя карьера в основном вращается вокруг внутренних бизнес-приложений - формализации и оптимизации операций бизнеса. В таких приложениях, как правило, существует бизнес-кругооборот, связанный с CRUD и сложными операциями. В больших объектах мои модели представлений оказываются очень простыми коллекциями однострочных функций-оболочек методов бизнес-класса и, в конце концов, только усложняют простейшие задачи, такие как показ окна сообщения или открытие окна. Неужели никто не находит странным, когда люди сталкиваются с длительным различением «внедрения зависимостей» и «провайдеров обмена сообщениями» для вызова Window.ShowDialog, который существует уже десятилетия? Сколько еще вопросов о переполнении стека просят совета относительно задач, которые были чрезвычайно просты в winforms?

Не поймите меня неправильно - я получаю MVVM и то, как он может быть неоценимым для больших команд, занимающихся горизонтальной разработкой упакованного в пакет программного обеспечения. Модульное тестирование моделей представлений может сэкономить миллионы, избежав серьезной ошибки RTM, а разработчики специализированных интерфейсов могут дать богатый опыт. Но когда стоимость перераспределения минимальна, и все заботы бизнеса окупаются за простое работающее программное обеспечение, почему я должен тратить время на модульное тестирование простой «оболочки» vm, когда моя бизнес-логика уже модульно протестирована? Сколько времени бизнес действительно позволит мне потратить на милые анимации и цветовые схемы? Есть ли что-то, что осталось сделать младшему разработчику (отслеживание ошибки в функции сохранения, которая раньше смотрела на «Save_Click»,

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

Для тех, кто может иметь отношение, можете ли вы указать мне на ресурсы, книги или даже просто изменения в перспективе, которые облегчили его проглатывание. Я еще раз попробую MVVM, но в прошлый раз я чувствовал себя довольно глупо из-за беспокойства по поводу внедрения зависимостей, просто чтобы показать окно сообщения от виртуальной машины, которое я не собирался тестировать. Даже если бы я проводил модульное тестирование, действительно ли мы получаем больше качества, торгуя во время выполнения тестирование на ошибки времени компиляции этих ужасно «тесно связанных» приложений?

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

Моя точка зрения основана на многолетнем опыте работы с Winforms, «старомодным способом», с событиями и программным обеспечением. Поэтому я могу с полной уверенностью сказать, что, как только вы выйдете за рамки простейших приложений, ваш код быстро превратится в большой шарик грязи . Это было неизбежно, потому что так были написаны приложения тогда.

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

Веб-формы - это ложь. Это абстракция, завернутая в обман, покрытый соусом лжи, представленный на тарелке, полной развлечения и ловкости рук. Ничто из того, что вы делаете с Webforms, не имеет ничего общего с Web - вы позволяете ему делать всю работу за вас.

Это от парня, который написал полностью функциональный объектно-реляционный маппер, используя dynamicключевое слово в C # и только четыреста строк кода. Когда он авторитетно о чем-то говорит, я слушаю.

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

У меня есть статический метод, с помощью которого я могу передать форму и наборы пар ключ / значение, и он (используя Reflection) автоматически сопоставит ключи с полями формы и заполнит форму значениями коллекции. Я также могу сделать обратное, получив набор пар ключ / значение из полей формы. Все это составляет около двадцати строк кода, но оно окупается каждый раз, когда я его использую, потому что мне не нужно писать сорок пользовательских операторов присваивания для сорока элементов управления в форме.

Я могу взять этот список Key / Value и сериализовать его в XML, что позволит мне сохранить его в файле. У меня есть другие формы, которые я могу передать обычному DTO и сопоставить его поля с формой. Ничто из этого не было бы практичным в стиле Winforms "большой шарик грязи". Это почти тривиально, когда используется адекватная развязка.

Что-нибудь из этого звучит знакомо? Должно; по сути, это форма привязки данных бедного человека.

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

Повезло тебе. Это не должно быть MVVM-совместимым. Но помните, шаблоны типа MVVM были созданы, чтобы помочь разработчикам создавать большие системы. Если вам просто нужно отобразить диалоговое окно, вам может не понадобиться вся эта сантехника.

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

Рассмотрим библиотеку Джона Резига jQuery: она является самой сущностью целостного дизайна и скрывает множество странных деталей о DOM и различных способах работы браузеров. Разве проще написать несколько строк Javascript? Иногда. Но преимущество написания кода jQuery в последовательном, унифицированном API облегчает следующему человеку, который придет, понять, что вы сделали, и поддерживать этот код, если это необходимо.

Мой реальный опыт работы с моделями «больших приложений» заключается в использовании ASP.NET MVC. ASP.NET для ASP.NET MVC, как Winforms для WPF. Когда я работал в ASP.NET, я всегда пытался подчинить его своей воле. ASP.NET MVC наклоняется к вам. Это радость в использовании; он создает структуру системы, которая является четкой и организованной, и дает вам полный контроль над вашим приложением и разметкой. Вы можете свободно использовать Javascript, jQuery и CSS, а ASP.NET MVC остается в стороне.

Моим единственным препятствием было привыкание к нему и знакомство с ним на собственных условиях.

Дальнейшее чтение,
вы должны изучить MVC Роб Конери