Аннотация: Должен ли я выбирать ASP.Net MVC поверх веб-форм или

Ответ 1

Я боюсь, что MVC может привести к сложная\длинная система, в которой поток является длительным. Я заблужусь? Это масштабируемо, если я хорошо организовываю?

Ну, часть этого зависит от того, насколько быстро вы подберете технологию.

В целом ASP.NET MVC столь же масштабируема, как и любое решение WebForms, и, по моему ограниченному опыту, возможно, даже более того. Вы должны помнить, что MVC - это шаблон, который не является новым - он использовался разработчиками приложений в течение многих лет. Это даже не ВСЕ, что ново для веб-разработки, хотя ASP.NET MVC делает очень легким сделать, что является одним из его призывов.

Некоторые из традиционных преимуществ ASP.NET MVC, такие как, например, тестирование, имеют большое значение для упрощения и упрощения создания общего проекта. Я создал свой первый веб-сайт ASP.NET MVC в течение недели, подключившись к библиотекам, которые были разработаны несколько лет назад, но предоставил интерфейсный веб-интерфейс. Это действительно было так просто.

Вопрос, который вы задали: "Я заблужусь?" действительно зависит от вас и приложения, которое вы разрабатываете, но только вы можете ответить на него. Вы должны быть готовы уделить время изучению и пониманию MVC... потому что вы исходите из фона WebForms, будут изменения, которые вам не знакомы.

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

Обновление. Мой собственный опыт работы с MVC был чрезвычайно положительным. Я знаю и понимаю WebForms только из-за использования его в течение последних нескольких лет, но недавно я начал проект в своей компании, и, поскольку мне дали свободу выбора технологий, которые я хотел использовать, я решил, что было бы интересно попробуйте модель MVC в веб-приложении (требуется веб-приложение). Моя команда и я имели опыт работы с MVC в настольных приложениях, но все мы были неопытны в отношении веб-разработки в целом (в целом).

Опыт ASP.NET MVC был чрезвычайно плавным, и это был легкий переход для моей команды. Я заказал несколько книг для команды, мы потратили немного времени на то, чтобы приблизиться к нашему пониманию, и тогда мы начали развиваться (требования уже были выполнены до этого шага - мы были на стадии реализации). Как я уже говорил, это заняло неделю, и мы уже совершили большие скачки вперед - производительность была и остается очень высокой. Я очень доволен моделью MVC.

Вы, похоже, обеспокоены тем, что модель MVC приведет к тому, что ваше приложение превратится в кучу каши или станет неудобным для обслуживания. В целом это далеко не так. Вся идея разделенных проблем делает MVC идеальным для масштабируемости приложения, а также для повышения его ремонтопригодности и тестируемости. С учетом сказанного, многое из того, насколько хорошо растет приложение, зависит от понимания вашей команды парадигмы MVC и их навыков в качестве разработчиков. MVC не для всех, и не для каждого проекта. Есть также много других факторов, которые следует учитывать в отношении масштабируемости, которая не имеет ничего общего с MVC (дизайн базы данных, например, имеет ОГРОМНОЕ воздействие - возможно, больше, чем любая парадигма развития, которую вы выбираете). Мне лично нравится ASP.NET MVC, и у меня был очень хороший опыт, но вы должны принять во внимание все аспекты вашего проекта (члены команды, выделенное время, бюджет и т.д.), Чтобы принять окончательное решение.

Ответ 2

Я использовал MVC с момента его первого выпуска. Моя основная причина желания использовать MVC была связана с тем, что время загрузки SEO/страницы является важным фактором в создаваемых веб-приложениях, и я устал от того, что другие разработчики злоупотребляют ViewState в наших приложениях, несмотря на мои частые объяснения относительно того, почему 80 тыс. ViewState на домашней странице неприемлема.

Я хотел использовать Маршрутизирующий движок для прекрасных URL-адресов RESTful, поскольку в тот момент, когда я использовал IIS7 для перезаписи url на производстве, но не имел его на моей машине dev. Использование маршрутизации означало, что мне не пришлось снова настраивать правила перезаписи при развертывании в IIS7, поскольку маршруты находятся в коде внутри приложения. Механизм маршрутизации теперь доступен в ASP.Net 4.0 Web Forms, поэтому вы можете легко переключаться с параметров QueryString.

Примечание. Вы спрашиваете, где можно хранить временные данные, такие как индекс страницы, порядок сортировки и т.д. Я обычно привязываю их к URL-адресу. Этот подход работает как с Web Forms, так и с MVC, например.

http://example.com/products/1/asc

http://example.com/products/2/desc

Когда я впервые использовал MVC, я сразу заметил, что управление и проверка состояния занимает больше времени, чтобы реализовать пользовательские формы со многими полями, флажками, выпадающими списками и т.д. Это увеличит ваше время разработки, поскольку вам нужно написать собственный код для сохранения состояния, и если вы хотите, чтобы проверка на стороне клиента JavaScript была необходима, вам нужно также перевернуть свой собственный, т.е. не требуется никаких необходимых валидаторов полей. ViewState не является злом, и легко свернуть ViewState в приложении Web Form. Разработчик, злоупотребляющий ViewState, является злым.

В целом многие функциональные требования, о которых вы говорите, например. фанковые функции графического интерфейса, переписывание URL-адресов, в отличие от параметров строки запроса, вычислений и т.д., могут быть достигнуты как с MVC, так и с Web-формами, и с точки зрения конечного пользователя веб-сайт будет выглядеть одинаково. Самое большое, что предлагает MVC, - это условное обозначение шаблона проектирования. Причина, по которой я заставил MVC в моей команде разработчиков, заключается в том, что я хотел, чтобы разработчики в команде придерживались одного и того же соглашения и, таким образом, позволяли нам легче находить код друг друга. То, что я также люблю в MVC, заключается в том, что сделать SoC (Разделение проблем) намного проще. Вы не упоминаете TDD (тестовое развитие) в своем сообщении, но сделать TDD проще для достижения - это то, что MVC также приносит в таблицу.

Ответ 3

В настоящее время я работаю над веб-приложением ASP.NET MVC и смотрю как на Java Spring, так и на Rails в свое время, и если вы готовы работать за пределами экосистемы Microsoft, я настоятельно рекомендую Rails как наиболее продуктивный из трех. Обман подскажет вам, что он на 10 раз быстрее, и из того, что я видел, похоже, это реальность, а не просто реклама.

Также из того, что я прочитал, ASP.NET MVC берет на себя большую часть дизайна от рельсов, но без повышения производительности и простоты использования.

И да, я понимаю, что у вас нет опыта вне экосистемы Microsoft, но рельсы очень просты в освоении по сравнению с ASP.NET MVC и Java Spring/JSF, и стоит того, что нужно изучить.

Дай мне голос, я тебя осмеливаюсь.