Является ли MVVM убийством разработки Silverlight?

Question

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

Моя точка зрения заключается в том, что узоры отличные, когда они решают какую-то проблему. Иногда только часть шаблона решает определенную проблему, в то время как другие ее части вызывают разные проблемы. Цель любого разработчика - создать надежное приложение, используя комбинацию шаблонов, которые знают как и предвидение.

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

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

EDIT: Могу ли я просто добавить как отредактировать, я использую и соглашаюсь с MVVM как шаблон, который я знаю, когда он есть, и невозможен в моих проектах. Моя проблема связана с всеобъемлющим характером, который он принимает, как будто он должен использоваться как часть развития. Он используется как неотъемлемая черта, а не шаблон, какой он есть.

EDIT 2: Спасибо за все комментарии до сих пор, одна проблема, которая всплывает от этого, - это то, о чем я не думал до сих пор. Является ли внедрение более богатых более продвинутых инфраструктур для разработки GUI/RIA, показывая слабость разработки RAD для этого поколения. То есть, существует ли недостаток в разработке кода и знаний о шаблонах, которые преподаются вместе с этими структурами? Я как-то попросил книгу только на C# (до Pro C# & .Net framework был популярен), и мне сказали, почему я хочу знать C# минус winforms/asp.

Уверены, что на эти темы много книг/КБ, но люди используют их, за пределами суперзвезд и очень хороших программистов?

Answer 1

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

Answer 2

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

Answer 3

Why can't you?

И нет, MVVM только один из многих моделей и, честно говоря, даже не среди самых популярных из них. Что усугубляет развитие Silverlight: a) Flash b) не является Flash c) является ориентированным на Microsoft d) кривой обучения.

Плюс тот факт, что WPF, похоже, не поймал, не очень помогает.

Answer 4

У кого-то есть проблемы с выяснением того, как использовать навигационную среду с MVVM => Кто-то не использует навигационную инфраструктуру => MVVM убивает навигационную среду => MVVM убивает разработку Silverlight.

Не могли бы вы сказать, что есть несколько недостатков этой цепочки рассуждений?

Answer 5

Я использую MVVM для приложения Windows Phone 7.Мне очень нравится идея этого, но слишком много хаков, словесных и сторонних инструментов, необходимых для его запуска.

Все становится лучше с каждым выпуском Silverlight, но я все же думаю, что технология «кровоточит».

Answer 6

Предполагая, что ваш вопрос применим и к WPF, мне кажется, что проблема заключается не только в массивной кривой обучения WPF/Silverlight, прежде чем вам даже придет в голову попробовать MVVM. Подумайте обо всех новых вещах, которые нужно изучить с помощью WPF (и я предполагаю Silverlight): XAML, свойства зависимостей, вложенные свойства, маршрутизируемые события, маршрутизируемые команды, статические ресурсы, динамические ресурсы, стили, шаблоны данных, шаблоны управления, привязка данных, и т. д. и т. д. и т. д. Затем примите тот факт, что Microsoft выпустила эту технологию с неполным набором, по крайней мере с WPF, плохо обработанными элементами управления, и у вас есть рецепт разочарования и неизбежного чувства, что вы имеете дело с технологией, которая «не готов к прайм-тайм». Я имею в виду, что до выхода инструментария WPF не было даже правильного элемента управления DataGrid.

Как только вы все это понимаете, MVVM - еще одно препятствие, но я не думаю, что это основное препятствие для людей, прыгающих на победителя WPF/Silverlight. Тем не менее, было бы неплохо, если бы Microsoft позаботилась о том, как она отстала от ASP.NET MVC. Как и сегодня, вам необходимо загрузить и использовать сторонние инструменты, такие как MVVM Foundation и MVVM Toolkit (которые, кстати, имеют много перекрытий и должны быть объединены в один проект).

Итак, я согласен с вами в какой-то момент, но я думаю, что большинство проблем, связанных с MVVM, вероятно, связано с отсутствием поддержки со стороны Microsoft и присущей сложности WPF/Silverlight, а не из-за какого-либо недостатка в сам шаблон MVVM.

Answer 7

Отличные ответы здесь, между прочим. Хорошее обсуждение и важно иметь. Нет никаких сомнений в том, что обучение Silverlight может быть пугающим для новых разработчиков, и структура MVVM, без сомнения, будет сочетать это.

Однако я согласен с тем, что кто-то не понимает, что это не расколоть рамки. У меня все еще есть разработчики, которые говорят мне, что инверсия инъекции управления/зависимости слишком запутанна, чтобы учиться, но делает ли это неправильные шаблоны? Тот факт, что так доказано, что «в поле» программное обеспечение опирается на эти концепции, говорит мне, что они звучат, даже если их сложно понять или понять.

С другой стороны, изучение иностранного языка было трудным, когда я начал, но как только я проскочил, теперь я могу говорить об этом комфортно и удивляться, почему так трудно начинать.

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

Если вы делаете игру с астероидами, фэнтезийной игрой, медиа-сайтом, выбиванием YouTube и т. Д., То вам, вероятно, не нужен MVVM, и это слишком много. Если вы строите небольшой сайт с несколькими формами и графиками, тогда создайте его, как вам удобно, и сделайте с ним.

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

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

Я имею в виду, действительно, пример просто говорит мне, что проблема не в MVVM, это разработчик. «Избежать навигации из-за MVVM?» ДЕЙСТВИТЕЛЬНО? Что MVVM связано с этим? Напишите элементы навигации, и пусть модели просмотра живут внутри страниц. Почему моя навигационная система должна работать с моделью просмотра?

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

Я знаю, что есть много движений, чтобы сварить его и сделать его простым для «среднего потребителя», но я думаю, что это похоже на попытку сказать: «Исчисление - это неправильный способ найти область под кривой, потому что она слишком трудно учиться ». В то время как MVVM не такой сложный, как Calculus, комплексное программное обеспечение здания является сложным делом, и я не думаю, что вы когда-либо упростите его или сводите его к простой формуле (и не должны). Если вы боретесь с MVVM, пожалуйста, не используйте его - найдите что-то более простое и легкое. Если ваш проект достаточно сложный, чтобы использовать его, и вы все еще не понимаете его, нанять кого-то, кто это сделает, попросите их выложить его и узнать у них.

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