Аннотация: стоит ли выбирать ASP.Net MVC через веб-формы или [закрыто]
Я работаю с web более 7 лет, и я обновился с html - >ASP - >ASP.Net а теперь новые ароматы ASP.Net себя. Я должен был начать с MVC в прошлом году, но из-за крайнего срока и сложности, связанной с MVC, я не мог. Теперь, еще раз есть новое обновление - я начал с ASP.Net Шаблоны DD (динамические данные) (последний, который формирует таблицы БД и дает список, детали, мастер редактирования и удаления).
когда я копаю, я узнаю, что он основан на MVC и поэтому я собираюсь использовать MVC (через DD) для создания моих веб-приложений. Я просмотрел много статей и видео сравнения между MVC и веб-формами. Есть много тем даже на SO, мои абстрактные ссылки находятся в разделе ниже ссылки. Действительно, MVC оказывается более "контролируемым" и "расширяемым" шаблоном веб-разработки, однако, как говорят некоторые, веб-формы все еще находятся рядом с ним (например, для создания тяжелых приложений, управляемых данными, и т. д.. т. е. Sharepoint)
мои веб-решения предназначены для цепочки поставок (пользователь должен войти в proced) и поэтому я не нужны функции SEO или другие вещи, полезные для типичной сети. Чтобы упростить, я делаю некоторые инвентаризации ведение (просмотр, добавление/редактирование, удаление & ссылка) экраны и несколько сложных экраны, такие как родительско-дочерние сетки и некоторые табличные макеты. Цель остается держать вещи простыми, но привлекательными и @ ядр мы имеем представление & практичность (большинство работает с наименьшими щелчками)
Итак, вот несколько из мой сомнения!--11--> как Новичок MVCian:
- веб-формы управляются событиями, где MVC будет делать это с помощью действий, определенных в контроллерах
- не имеет значения, использую ли я L2S или EF, моя бизнес-логика идет в модели (также расширенной частичными классами)
- URL-маршрутизация расширит мою власть за пределы традиционного подхода Querystring
- я смогу отображать каскадные сложные табличные макеты и сетки, используя несколько видов (т. е. частичные представления и пользовательские элементы управления)
- такие вещи, как sub-total, Grand-total и т. д.. вид расчетов будет возможен в представлениях (надеюсь, что представления могут обмениваться / передавать данные взаимно)
- какой-то стремный интерфейс функции, такие как замороженные сетки-верхний/нижний колонтитул, прокрутка строк, вкладка-Вид, и т. д.. не приведет меня к грязному виду (или, по крайней мере, это возможно в чистом/организованном виде)
- у меня действительно не будет "Viewstate" - в этом случае, где хранить временные данные? как текущий pageindex, порядок сортировки, так далее..
- я боюсь, что MVC может привести к сложнойlenghty системе, где поток длинный. Я потеряюсь? Масштабируемо ли это, если я хорошо организовываюсь?
на самом деле, theres больше, но я надеюсь, что на основе вышеуказанных Qs Вы, эксперты, можете выяснить, какие веб-приложения я работаю, и поэтому я просто хочу начать инвестировать в что-то лучшее. Не могу позволить себе менять архитектуру / подход каждые 6 месяцев!
делает ли DD MVC неявным? Как тогда может ли он использовать элементы управления web-form? Извините, если я запутался, в таком случае, пожалуйста, поправьте меня!(большинство работает с наименьшими щелчками)
наконец, может ли это быть решением: http://www.hanselman.com/blog/PlugInHybridsASPNETWebFormsAndASPMVCAndASPNETDynamicDataSideBySide.aspx
Также см. раздел редактирование.
ссылки url: (надеюсь, это поможет другим, как я)
Some хорошие ссылки о MVC над web-froms & сравнение -
http://forums.asp.net/t/1459417.aspx (преимущества MVC над хорошо разработанным приложением веб-форм) http://www.matthidinger.com/archive/2010/02/17/why-i-love-asp.net-mvc.aspx
огонь в дыре :-) http://codebetter.com/blogs/karlseguin/archive/2010/03/11/webforms-vs-mvc-again.aspx http://www.codethinked.com/post/2010/0 http://www.codethinked.com/post/2010/01/22/Controls-Do-Not-Make-You-More-Productive.aspx
больше в этой дискуссии:
В. хорошая статья: http://msdn.microsoft.com/en-us/magazine/dd942833.aspx
резюме выше: http://mvark.blogspot.com/2009/08/aspnet-mvc-vs-web-forms.html
http://www.asp.net/mvc/tutorials/asp-net-mvc-overview--cs http://weblogs.asp.net/shijuvarghese/archive/2008/07/09/asp-net-mvc-vs-asp-net-web-form.aspx http://codebetter.com/blogs/karlseguin/archive/2010/03/11/webforms-vs-mvc-again.aspx
так:
http://stackoverflow.com/questions/30067/
http://stackoverflow.com/questions/361620/asp-net-mvc-vs-webforms-for-first-page-load-speed-for-big-projects/
http://stackoverflow.com/questions/712220/whats-your-choice-for-your-next-asp-net-project-webforms-or-mvc/
http://stackoverflow.com/questions/661181/asp-net-mvc-vs-webforms/
http://stackoverflow.com/questions/1035642/asp-net-mvc-vs-webforms-speed-and-architecture-comparison/
http://stackoverflow.com/questions/837831/mvc-versus-webforms/
изменить #1:
Спасибо за экспертные комментарии и обзор. Я хотел бы поделиться некоторыми из моих экранов - если кто-то заинтересован, чтобы вы знали, какие функции GUI и сетки каскадирования я использую -
Plz не путайте меня с новичком web-dvpr. Мне просто нужно знать (например, когда я говорю "буду ли я потерян"), достижимо ли достижение многофункционального GUI и каков ваш опыт в таких вещах .. надеюсь, что помогает :-)
3 ответов
Я боюсь, что MVC может привести к сложная\длинная система, где поток это долго. Я потеряюсь? Это масштабируемый, если я хорошо организовываю?
Ну, часть этого зависит от того, как быстро вы подберете технологию.
в целом, ASP.NET MVC так же масштабируема, как и любое решение WebForms, и, по моему ограниченному опыту, возможно, даже больше. Вы должны помнить, что MVC-это шаблон, который не является новым - он был использован по применению разработчики годами. Это даже не все, что новое для веб-разработки, хотя ASP.NET MVC делает это очень легко сделать, что является одним из его обращений.
некоторые из традиционных преимуществ ASP.NET например, MVC, например, testability, значительно упрощает обслуживание и быстрее создает общий проект. Я построил свой первый ASP.NET веб-сайт MVC в течение недели, подключаясь к библиотекам, которые были разработаны несколько лет назад, но обеспечивая интерфейсный веб-интерфейс. Все действительно было так просто.
вопрос, который вы задали: "я потеряюсь?"действительно зависит от вас и приложения вы разрабатываете, но только вы можете ответить. Вы должны быть готовы потратить время на изучение и понимание модели MVC...поскольку вы исходите из фона WebForms, будут изменения, которые вам не будут знакомы.
в любом случае, я лично рекомендую использовать MVC, но, как всегда, это зависит от вашего проекта по необходимости.
обновление: мой собственный опыт работы с MVC был чрезвычайно положительным. Я знаю и понимаю WebForms только из-за его использования в течение последних нескольких лет, но недавно я начал проект в своей компании, и, поскольку мне дали свободу выбора технологий, которые я хотел использовать, я решил, что было бы интересно попробовать модель MVC в веб-приложении (веб-приложение является требованием). Моя команда и я имели опыт работы с MVC в desktop приложения, но мы все были неопытны в веб-разработке в целом (в целом).
ASP.NET опыт MVC был чрезвычайно гладким, и это был легкий переход для моей команды. Я заказал несколько книг для команды, мы потратили немного времени на то, чтобы ускорить наше понимание, а затем начали развиваться (требования уже были выполнены до этого шага - мы были на этапе реализации). Как я уже говорил ранее, это заняло неделю, и мы уже сделали большой скачок вперед-производительность была и остается очень высокой. Я очень доволен моделью MVC.
вы, похоже, обеспокоены тем, что модель MVC заставит ваше приложение превратиться в кучу кашицы или стать громоздким для обслуживания. В целом, это далеко от истины. Вся идея разделенных проблем делает MVC идеальным для масштабируемости приложения, а также повышения его ремонтопригодности и тестируемости. С учетом сказанного, много, насколько хорошо приложение рост зависит от понимания вашей командой парадигмы MVC и их навыков как разработчиков. MVC-это не для всех, не для каждого проекта. Есть также много других факторов, которые следует учитывать в отношении масштабируемости, которая не имеет ничего общего с MVC (например, дизайн базы данных оказывает огромное влияние - вероятно, больше, чем любая парадигма развития, которую вы выбираете). Лично мне нравится ASP.NET MVC, и имели очень хороший опыт работы с ним, но вы должны принять во внимание все аспекты вашего проекта (члены команды, сроки, бюджет и т. д.), чтобы принять окончательное решение.
Я использую MVC с момента его первого выпуска. Моя основная причина желания использовать MVC была связана с тем, что время загрузки SEO/страницы является важным фактором в веб-приложениях, которые я создаю, и я устал от других разработчиков, злоупотребляющих ViewState в наших приложениях, несмотря на мои частые объяснения о том, почему 80k ViewState на главной странице неприемлемо.
Я хотел использовать механизм маршрутизации для прекрасных URL-адресов RESTful, поскольку в тот момент я использовал IIS7 для перезаписи url на производстве, но не был доступен на моей машине dev. Использование маршрутизации означало, что мне не нужно было настраивать правила перезаписи снова при развертывании в IIS7, так как маршруты находятся в коде в приложении. Механизм маршрутизации теперь доступен в ASP.Net 4.0 веб-формы, так что вы можете легко переключаться с помощью параметров QueryString.
Примечание: Вы спросите, где можно хранить временных данных, таких как индекс страницы, порядок сортировки и т. д. Я обычно помечаю их на URL. Этот подход работает как с веб-формами, так и с MVC, например
http://example.com/products/1/asc
http://example.com/products/2/desc
когда я впервые использовал MVC, я сразу заметил, что управление состоянием и проверка занимают больше времени для реализации пользовательских форм со многими полями, флажками, выпадающими списками и т. д. Это увеличит время разработки, так как вам нужно написать пользовательский код для сохранения состояния, и если вы хотите клиентскую сторону JavaScript валидация вам также нужно свернуть свои собственные, т. е. нет обязательных валидаторов полей. ViewState не является злом, и его легко минимизировать в приложении веб-формы. Разработчик, который злоупотребляет ViewState, является злым.
в резюме многие из функциональных требований, которые вы упоминаете, например, фанки функции GUI, переписывание url в отличие от параметров строки запроса, расчеты и т.д. могут быть достигнуты как с MVC и веб-форм и с точки зрения конечного пользователя веб-сайт будет выглядеть одинаково. Самое большое, что предлагает MVC, - это соглашение о шаблоне дизайна. Причина, по которой я заставил MVC в моей команде разработчиков, заключается в том, что я хотел, чтобы разработчики в команде следовали тому же соглашению и, таким образом, позволяли нам легче подбирать код друг друга. Что мне также нравится в MVC, так это то, что это делает SoC (разделение проблем) намного легче достичь. Вы не упоминаете TDD( test driven development) в своем посте, но упрощение TDD-это то, что MVC также приносит в таблица.
в настоящее время я работаю над ASP.NET MVC веб-приложение и посмотрел на Java Spring и Rails в свое время, и если вы готовы работать за пределами экосистемы Microsoft, то я настоятельно рекомендую Rails как наиболее продуктивный из трех. Шумиха скажет вам, что это в 10 раз быстрее, и из того, что я видел, это кажется реальностью, а не просто шумихой.
также из того, что я прочитал ASP.NET MVC принимает много его дизайн от рельсов но без производительность и простота использования.
и да, я понимаю, что у вас нет опыта вне экосистемы Microsoft, но rails очень легко узнать по сравнению с ASP.NET MVC и Java Spring / JSF и стоит усилий, которые потребуются для обучения.
вниз голосовать меня я смею вас.