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

9

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

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

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

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

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

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

b_levitt
источник
1
Хотя я не поощряю это, все еще возможно написать приложение для WinFms в стиле WPF с событиями и кодом позади. Для простых одноразовых приложений это не имеет большого значения. Все сводится к тому, что вы цените и что обеспечивает ценность для бизнеса. Я большой поклонник TDD и MVVM, но если это действительно не обеспечивает ценность, не делайте этого. Это не религия. Просто помните, что код часто живет намного дольше, чем мы думаем.
Мэтт Х
«Неужели никто не находит странным, когда люди сталкиваются с длительным различением« внедрения зависимостей »и« поставщиков сообщений »для вызова Window.ShowDialog, который существует уже десятилетия?» Я нахожу это раздражающим, но тот человек, который занимается всем этим (в ущерб тому, чтобы действительно что-то сделать), всегда был частью поля, и, к сожалению, вероятно, всегда будет. Лучшая стратегия - игнорировать / отвлекать их как можно больше.
user1172763

Ответы:

10

Моя точка зрения основана на многолетнем опыте работы с 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 Роб Конери

Роберт Харви
источник
Спасибо за действительно вдумчивый ответ, большой комок грязи - я определенно чувствовал это во времена классического кода на оспы и спагетти. Трехуровневый дизайн с vb6 / mts исправил многое, а затем в выпуске .net все это собралось. Но теперь, если вы чувствуете, что отдача от дополнительных паттернов быстро снижается - например, потратить 1 млн. Долл., Чтобы сэкономить 0,1 сек. За четверть мили. «Я активно выдвигал каждый фрагмент кода, который мог, в отдельную сборку» - разве вы не находите, что это дает невероятно раздробленный опыт разработки - постоянно переходя от файла к файлу, чтобы прочитать две строки?
b_levitt
3
don't you find that this gives an incredibly fractured development experience - constantly jumping from file to file to read two lines?- Нет, это наоборот. Помещение в другую сборку, подобную этой, освобождает ваш ум, чтобы сосредоточиться на каждом классе и методе на их собственных терминах, как на собственном маленьком черном ящике. Это очень трудно сделать с большим шариком грязи. MVC работает по тому же принципу: тонкие контроллеры, толстая модель, без кода в представлении, если это не является абсолютно необходимым.
Роберт Харви
3
Ягни применяется только тогда, когда вы пишете код самостоятельно. Если вы пишете обобщенную библиотеку, которая должна удовлетворить широкую аудиторию с различными потребностями, она вам понадобится.
Роберт Харви
1
Кстати, я ничего не имею против жизненного цикла ASP.NET; Я видел, как люди используют это с превосходным эффектом. Я просто нахожу это нелогичным, вот и все. ASP.NET MVC не заставляет вас заниматься разработкой на стороне клиента, если вы этого не хотите; Вы можете использовать «тупые» представления, и это прекрасно работает. Стоит отметить: многие из этих вещей могут быть сгенерированы кодом (как в форме Windows), так что вы не пишете весь код самостоятельно. Я понимаю, что это не так с WPF, где вам приходится иметь дело с XAML, и я думаю, что здесь есть возможности для улучшения.
Роберт Харви
2
dozens of lines of plumbing to replace Window.Show- Это немного упрощение. Если окну нужны данные, всегда будет что- то вроде сантехники, чтобы передать эти данные в элементы управления окна, и наоборот. Вы можете либо писать этот повторяющийся код снова и снова для каждой создаваемой вами формы, либо использовать некоторую форму обобщенного решения, например привязку данных.
Роберт Харви