Кто-нибудь кроме меня просто НЕ получает ASP.NET MVC? [закрыто]

Используйте Шаблон Фасада для обертывания всей логики для всех данных, необходимо отобразить и затем использовать его в качестве дженерика в представлении и затем.... больше запутанного кода. http://en.wikipedia.org/wiki/Design_pattern _ (computer_science)

, Если Вам нужно больше cgardner2020@gmail.com

JSPs EE Java был похож на это, когда они были сначала предложены - ужасный код scriptlet.

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

я думаю, что лучшим решением является Библиотека тегов стандарта JSP (JSTL). Это "стандартно", выход HTML-тэга, и помогает препятствовать тому, чтобы люди поместили логику в страницы.

дополнительное преимущество - то, что это сохраняет ту строку разграничения между веб-разработчиками и разработчиками. Хорошие сайты, которые я вижу, разработаны людьми с эстетическим смыслом и разрабатывающий для удобства использования. Они размечают страницы и CSS и передают их разработчикам, которые добавляют в динамических битах данных. Говоря как разработчик, который испытывает недостаток в этих подарках, я думаю, что мы даем что-то важное далеко, когда мы просим, чтобы разработчики записали веб-страницы от супа до гаек. Flex и Silverlight пострадают от той же проблемы, потому что маловероятно, что разработчики будут знать JavaScript и Ajax хорошо.

, Если бы.NET имела путь, подобный JSTL, я советовал бы, чтобы они изучили его.

Я использовал MVC для того, так как Предварительный просмотр 3 вышел и в то время как это, все еще имеет, это - болезнь роста, это помогает вполне немного в области разработки команды. Попытайтесь иметь три работы человек на единственной странице веб-форм, и затем Вы поймете понятие стука по Вашей голове на стене. Я могу работать с разработчиком, который понимает элементы дизайна на странице представления и нашем резидентном боге Linq в создании образцовой работы, в то время как я соединил все в контроллере. Я никогда не был в состоянии разработать в области, где разделения проблем было настолько легко достигнуть.

Самый большой коммерческий аргумент ASP.NET MVC - StackOverflow работает на стеке MVC.

, Что, будучи сказанным... Ваш код настолько более симпатичен, чем, что я обычно делаю со страницей представления. Кроме того, один из парней, с которыми я работаю, работает над обертыванием помощника HTML в библиотеку тегов. Вместо < % =Html. RandomFunctionHere () %> это работает как

< hh:randomfunction/>

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

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

1. Они предлагают формальное разделение между Операциями Базы данных, "Бизнес-логикой" и Представлением

2. , Они предлагают достаточно гибкости в представлении, чтобы позволить разработчикам настраивать свой HTML/CSS/Javascript для работы в нескольких браузерах, и будущие версии тех браузеров

, Это - этот последний бит, это - важное. С Веб-формами и подобными технологиями, Вы полагаетесь на своего поставщика для записи HTML/CSS/Javascript для Вас. Это - мощный материал, но у Вас нет гарантии, что текущая версия Веб-форм собирается работать со следующим поколением веб-браузеров.

Это - питание представления. Вы получаете полный контроль над HTML своего приложения. Оборотная сторона, Вы потребность, которая будет дисциплинироваться достаточно, чтобы сохранить логику в Ваших представлениях к минимуму и сохранить шаблон кода столь простым, как Вы возможно можете.

Так, это - компромисс. Если Веб-формы работают на Вас, и MVC не, то продолжают использовать Веб-формы

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

единственные люди я знаю, кто пытается реализовать MVC, люди, которым нравится пробовать новые вещи от MSFT. В демонстрациях я видел, у предъявителя был примирительный тон...

я - большой поклонник MSFT, но я должен сказать, что не вижу оснований для беспокойства их реализацией MVC. Или используйте Веб-формы или используйте jQuery для веб-разработки, не выбирайте это отвращение.

РЕДАКТИРОВАНИЕ:

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

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

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

Просто недавно я провел 2 дня, пытаясь выяснить лучший способ добавить подкачку страниц к "сетке" в MVC. Теперь, с веб-формами я мог выкрикнуть это в мгновение ока. Но я скажу это..., как только у меня были классы помощника подкачки страниц, созданные для MVC, стало чрезвычайно просто реализовать. Мне, еще легче, чем веб-формы.

Однако я думаю, что MVC будет намного большим количеством разработчика, дружелюбного, когда будет непротиворечивое множество Помощников HTML там. Я думаю, что мы собираемся начать видеть тонну всплывающего окна классов помощника HTML в сети в ближайшем будущем.

Два основных преимущества платформы MVC ASP.NET по веб-формам:

1. Тестируемость - UI и события в веб-формах почти невозможны для тестирования. С ASP.NET MVC, действия контроллера поблочного тестирования и представления, которые они представляют, легки. Это идет со стоимостью в оплачиваемых авансом затратах на разработку, но исследования представили в выгодном цвете это, это платит в конечном счете, когда они прибывают время, чтобы осуществить рефакторинг и поддержать приложение.
2. Лучшее управление представленным HTML - Вы заявляете, что не заботитесь о представленном HTML, потому что никто не смотрит на него. Это - допустимая жалоба, если это было единственной причиной правильно отформатировать HTML. Существуют многочисленные причины желания правильно отформатированного HTML включая: SEO, способность использовать идентификационные селекторы чаще (в css и JavaScript), меньшие места страницы из-за отсутствия состояния отображения и смехотворно длинных идентификаторов (ctl00_etcetcetc).

Теперь, эти причины действительно не делают ASP.NET MVC немного лучше или хуже, чем веб-формы в черно-белом виде пути. ASP.NET MVC имеет его достоинства и недостатки, точно так же, как веб-формы. Однако большинство жалуется на ASP.NET, который MVC, кажется, останавливают от отсутствия понимания того, как использовать его, а не фактические дефекты в платформе. Причина Ваш код не чувствует себя хорошо или выглядит правильным, мог бы быть то, потому что у Вас есть несколько лет опыта веб-форм под Вашим поясом и только 1-2 месяца ASP.NET опыт MVC.

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

Грандиозное предприятие с MVC состоит в том, что это - концептуальная основа, которая была около долгого времени, и это оказалось как продуктивный, мощный способ создать оба веб-приложения и приложения рабочей станции, которые масштабируются горизонтально и вертикально. Это переходит непосредственно назад к Alto и Smalltalk. Microsoft является поздней стороне. Что мы имеем теперь с ASP.NET, MVC действительно примитивен, потому что существует такое наверстывание, чтобы сделать; но чертовски, они наливают новые выпуски быстро и неистово.

, Каково было грандиозное предприятие с Ruby on Rails? Направляющие являются MVC. Разработчики преобразовывали, потому что, устно, это стало способом для программистов быть продуктивным.

Это - огромное соглашение; MVC и неявное подтверждение jQuery являются переломными моментами для Microsoft, признающей, что независимый от платформы очень важно. И то, что нейтрально об этом, то, что в отличие от Веб-форм, Microsoft не может привязать Вас концептуально. Можно взять весь код C#, и перереализация на другом языке полностью (скажите PHP или Java - Вы называете его), потому что это - понятие MVC, это портативно, не сам код. (И думайте, насколько огромный случается так, что можно взять разработку и реализацию это в качестве приложения рабочей станции с небольшим изменением кода и никакого конструктивного изменения. Попробуйте это Веб-формами.)

Microsoft решила, что Веб-формы не будут следующим VB6.

Я думаю, что Вы пропускаете некоторые вещи. Во-первых, нет никакой потребности в Ответе. Запишите, можно использовать <%= %> теги. Во-вторых, можно записать собственные расширения HtmlHelper, чтобы сделать общие действия. В-третьих, определенное форматирование помогает много. В-четвертых, все это, вероятно, застряло бы в пользовательском элементе управления, который будет совместно использован несколькими различными взглядами, и таким образом полные повышают в основном представлении, является более чистым.

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

Теперь, это не так плохо, и было бы еще лучше, если бы я не должен был форматировать его для ТАК.

 <%
    var PreviousPost = ViewData.Model.PreviousPost;
    var NextPost = ViewData.Model.NextPost;

    // Display the "Next and Previous" links
    if (PreviousPost != null || NextPost != null)
    {
  %>

 <div>

        <%= PreviousPost == null
                ? string.Empty
                : Html.ActionLinkSpan("<< " + PreviousPost.Subject,
                                "view",
                                new { id = PreviousPost.Id },
                                new { style = "float: left;" } ) %>
          <%= NextPost == null
                ? string.Empty
                : Html.ActionLinkSpan( NextPost.Subject + " >>",
                                   "view",
                                    new { id = NextPost.Id },
                                    new { style = "float: right;" } ) %>

  <div style="clear: both;" />
  </div>

  <% } %>

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

Другие ответы обсудили преимущества MVC в целом, таким образом, я сфокусируюсь на синтаксисе представления:

поддержка для использования HTML. ActionLink и другие методы, которые генерируют HTML, являются шагом в неправильном направлении. Это имеет привкус управления сервером, и, мне, решает проблему, которая не существует. Если мы собираемся генерировать теги от кода, то почему беспокойство с помощью HTML вообще? Мы можем просто использовать DOM или некоторую другую модель и создать наше содержание в контроллере. Хорошо, это звучит плохим, не так ли? Ах да, разделение проблем, именно поэтому у нас есть представление.

я думаю, что корректное направление должно сделать синтаксис представления максимально во многом как HTML. Помните, хорошо разработанный MVC должен не только дать Вам разделение кода от содержания, это должно позволить Вам оптимизировать свое производство при наличии людей, которые опытны в разметке на представлениях (даже при том, что они не знают ASP.NET), и затем позже как разработчик можно вступить и сделать макет представления на самом деле динамичным. Это может только быть сделано, если, если синтаксис представления очень походит на HTML, так, чтобы люди расположения могли использовать DreamWeaver или независимо от того, что текущий популярный разметочный инструмент. Вы могли бы создавать десятки сайтов сразу и должны масштабироваться таким образом для эффективности производства. Позвольте мне дать пример того, как я видел, что представление "язык" работало:

<span mvc:if="ViewData.Model.ShowPrevious" style="float: left;">
    <a mvc:inner="ViewData.Model.PreviousPost.Subject" href="view/{ViewData.Model.PreviousPost.Id}">sample previous subject</a>
</span> 
<span mvc:if="ViewData.Model.ShowNext" style="float: left;">
    <a mvc:inner="ViewData.Model.NextPost.Subject" href="view/{ViewData.Model.NextPost.Id}">sample next subject</a>
</span> 
<div mvc:if="ViewData.Model.ShowNextOrPrevious" style="clear: both;" />

Это имеет несколько преимуществ:

• взгляды лучше
• более краткий
• никакое броское контекстное переключение между HTML и < % %> теги
• легкий понять ключевые слова, которые очевидны (даже непрограммист мог сделать это - хороший для распараллеливания)
• как можно больше логики попятилось в контроллер (или модель)
• никакой сгенерированный HTML - снова, это делает очень легким для кого-то войти и знать, где разработать что-то, не имея необходимость бездельничать с HTML. методы
• код имеет демонстрационный текст в нем, который представляет, когда Вы загружаете представление как простой HTML в браузере (снова, хороший для людей расположения)

Так, что точно делает этот синтаксис?

mvc:inner = "" - независимо от того, что находится в кавычках, оценен, и внутренний HTML тега заменяется получившей строкой. (Наш демонстрационный текст заменяется)

mvc:outer = "" - независимо от того, что находится в кавычках, оценен, и внешний HTML тега заменяется получившей строкой. (Снова, демонстрационный текст заменяется.)

{} - это используется для вставки вывода в атрибутах, подобных < % = %>

mvc:if = "" - insde кавычки является булевым выражением, которое будет оценено. Завершение, если то, где HTML-тэг закрывается.

mvc:else

mcv:elseif = ""-...

mvc:foreach

<% if (Model.PreviousPost || Model.NextPost) { %>
    <div class="pager">
        <% if (Model.PreviousPost) { %>
            <span><% Html.ActionLink("<< " + Model.PreviousPost.Subject, "view")); %></span>
        <% } if (Model.NextPost) { %>
            <span><% Html.ActionLink(Model.NextPost.Subject + " >>", "view")); %></span>
        <% } %>
    </div>
<% } %>

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

ПРИМЕЧАНИЕ: ViewData. Модель становится Моделью в следующем выпуске.

И при помощи пользовательского элемента управления это стало бы

<% Html.RenderPartial("Pager", Model.PagerData) %>

, где PagerData инициализируется через анонимного конструктора в обработчике действий.

редактирование: мне любопытно, на что Ваша реализация WebForm была бы похожа для этой проблемы.

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

, Но в то же время у Вас есть несколько новых опций, которые Вы не имели прежде...

[еще 114] управление страницей и элементами в странице
2. Меньше "спама" в Вашем выводе, как ViewState или чрезмерно длинные идентификаторы на элементах (не понимают меня превратно, мне нравится ViewState)
3. Лучшая способность сделать клиентское программирование с JavaScript (Приложения Web 2.0 кто-либо?)
4. Не только просто MVC, но и JsonResult является гладким...

Теперь но это вовсе не значит, что Вы не можете сделать, любая из этих вещей с WebForms, но MVC облегчает.

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

И WebForms и MVC способны к абсолютному мусору, если Вы небрежны. Как всегда, тщательное планирование и хорошо продумал дизайн, приведет к качественному приложению, независимо если это будет MVC или WebForms.

[Обновление]

, Если это - какое-либо утешение также, MVC является просто новой, развивающейся технологией от Microsoft. Было много регистраций, которыми WebForms не только останется, но продолжит разрабатываться для...

http://haacked.com

http://www.misfitgeek.com

http://rachelappel.com

... и так далее...

Для обеспокоенных маршрутом MVC берет, я предложил бы дать "парням" Вашу обратную связь. Они, кажется, слушают до сих пор!

Я не уверен в том, о чем люди точки прекратили заботиться об их коде.

HTML является самым общедоступным дисплеем Вашей работы, существует МНОГО разработчиков там, которые используют блокнот, блокнот ++, и другие редакторы простого текста для создания большого количества веб-сайтов.

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

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

, Если Вам не нравится также, Вы определенно собираетесь быть выполнением примерно столько же работы в разметке.

РЕДАКТИРОВАНИЕ я Должен также заявить, что Веб-формы и MVC имеют свое место, я никоим образом не заявлял, что каждый был лучше, чем другой, только что каждый MVC имеет силу восстановления управления разметкой.

Я признаю, что еще не получаю asp.net MVC. Я пытаюсь использовать его в параллельном проекте, который я делаю, но это довольно не торопится.

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

До сих пор я заметил, что главная причина использовать MVC состоит в том, чтобы получить полный контроль над Вашим HTML. Я также считал, что asp.net, MVC в состоянии подать больше страниц быстрее, чем веб-формы и вероятно связанный с этим, отдельный размер страницы, меньше, чем средняя страница веб-форм.

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

Большинство возражений на ASP.NET, MVC кажется в центре вокруг представлений, которые являются одним из большинства "дополнительных" и модульных битов в архитектуре. NVelocity, NHaml, Spark, XSLT и другие механизмы представления могут быть , легко выгрузил (и это становилось легче с каждым выпуском). У многих из тех есть НАМНОГО более краткий синтаксис для того, чтобы сделать логику представления и форматировать при тихом давании полного контроля над испускаемым HTML.

Кроме того, почти каждая критика, кажется, сводится к < % %> отмечающий на представлениях по умолчанию и насколько "ужасный" это. То мнение часто базируется в том, чтобы быть привыкшимся к подходу WebForms, который просто перемещает большую часть классического уродства ASP в код - позади файла.

Даже, не делая кода-behinds "неправильно", у Вас есть вещи как OnItemDataBound в Повторителях, который является так же, как эстетически ужасен, если только по-другому, чем "суп тега". Цикл foreach может быть намного легче считать, даже с переменным встраиванием в вывод того цикла, особенно если Вы приезжаете в MVC от других технологий non-ASP.NET. Требуется намного меньше Google-fu для понимания цикла foreach, чем выяснить, что способ изменить то одно поле в повторителе состоит в том, чтобы смешать с OnItemDataBound (и вложенное множество крысы проверки, если это - правильный элемент, который будет изменен.

самая большая проблема с ASP управляемые тегом-супом "спагетти" была больше о пихающихся вещах как соединения с базой данных прямо посередине между HTML.

, Что это, оказалось, сделало настолько использующий < % %> является просто корреляцией с природой спагетти классического ASP, не причинной обусловленностью. Если Вы сохраняете свою логику представления к HTML/CSS/Javascript и минимальную логику необходимыми, чтобы сделать представление , остальное - синтаксис.

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

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

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

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

Большая часть моего разочарования им просто не знает, как сделать вещи "правильно". Так как это было выпущено как предварительный просмотр, у нас все было немного времени для рассмотрения вещей, но они изменялись вполне немного. Сначала я был действительно расстроен, но платформа кажется достаточно осуществимой, чтобы позволить мне создать чрезвычайно сложный UI (чтение: Javascript) довольно быстро. Я понимаю, что можно сделать это с Веб-формами, поскольку я делал его прежде, но это была огромная боль в торце, пытающемся заставить все представлять правильно. Много времен я закончил бы тем, что использовал повторитель для управления точным выводом и закончу с большой путаницей спагетти, которую Вы имеете выше также.

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

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

<if condition="myDtp.ShowPager">
  <div>
    <first />
    <last />
    <div style="clear: both;" />
  </div>
</if>

Это является довольно удобным в сопровождении, тестируемым, и является на вкус вкусным в моем супе кода.

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

Пожалуйста, взгляните на пост Роба Конери Я полагаю, я просто скажу: вы должны изучить MVC

Недавно опубликованная книга Стива Сандерсона «Pro ASP.NET MVC» [1] [2] от Apress предлагает другую альтернативу - создание собственного расширения HtmlHelper. Его пример (из главы 4 на стр. 110) использует пример постраничного списка, но его можно легко адаптировать к вашей ситуации.

public static string PostNavigator(this HtmlHelper html, Post previous, Post next, Func<int, string> pageUrl)
{
    StringBuilder result = new StringBuilder();

    if (previous != null || next != null)
    {
        result.Append("<div>");

        if (previous != null)
        {
            result.Append(@"<span class=""left"">");
            TagBuilder link = new TagBuilder("a");
            link.MergeAttribute("href", pageUrl(previous.Id));
            link.InnerHtml = String.Format("<< {0}", html.Encode(previous.Subject));
            result.Append(link.ToString());
            result.Append("</span>");
        }

        if (next != null)
        {
            if (previous != null)
            {
                result.Append(" ");
            }

            result.Append(@"<span class=""right"">");
            TagBuilder link = new TagBuilder("a");
            link.MergeAttribute("href", pageUrl(next.Id));
            link.InnerHtml = String.Format("{0} >>", html.Encode(next.Subject));
            result.Append(link.ToString());
            result.Append("</span>");
        }

        result.Append("</div>");
    }

    return result.ToString();
}

Вы бы назвали его, по вашему мнению, с кодом, похожим на этот:

<%= Html.PostNavigator(ViewData.Model.PreviousPost, ViewData.Model.NextPost, id => Url.Action("View", new { postId = id })) %>

[1] http: / /blog.codeville.net/2009/04/29/now-published-pro-aspnet-mvc-framework-apress/

[2] http://books.google.com/books?id=Xb3a1xTSfZgC

Я тоже; Я бы тратил время на Silverlight, а не на ASP.NET MVC. Я пробовал MVC 1.0 и несколько дней назад взглянул на последнюю версию 2.0 Beta 1.

Я (не могу) почувствовать, чем ASP.NET MVC лучше, чем веб-форма. Преимуществами MVC являются:

1. Модуль (тест)
   
2. Разделите дизайн (представление) и логику (контроллер + модель)
   
3. Отсутствие состояния просмотра и улучшенное управление идентификаторами элементов
   
4. RESTful URL и многое другое ...

Но веб-форма с использованием кода программной части. Тема, кожа и ресурс уже идеально подходят для разделения дизайна и логики.

Viewstate: управление идентификаторами клиентов входит в ASP.NET 4.0. Меня беспокоят только модульные тесты, но модульных тестов недостаточно, чтобы обратить меня на ASP.NET MVC из веб-формы.

Возможно, я могу сказать: ASP.NET MVC неплох, но веб-формы уже достаточно.

Теперь я могу говорить здесь только за себя:

ИМО, если вы упорный (что угодно), то преобразование не для вас. Если вам нравятся WebForms, то это потому, что вы можете делать то, что вам нужно, и это тоже цель.

Webforms отлично справляется с абстрагированием HTML от разработчика . Если это ваша цель, придерживайтесь веб-форм. У вас есть все замечательные функции «щелкни и перетащи», которые сделали настольную разработку тем, чем она является сегодня. Есть много включенных элементов управления (плюс множество сторонних элементов управления), которые могут обеспечивать различную функциональность. Вы можете перетащить «сетку», которая напрямую связана с источником данных из вашей базы данных; он поставляется со встроенными функциями встроенного редактирования, разбиения на страницы и т. д.

На данный момент ASP. NET MVC очень ограничен с точки зрения сторонних элементов управления. Итак, опять же, если вам нравится быстрая разработка приложений, где для вас настроено множество функций, вам не следует пытаться конвертироваться.

С учетом всего сказанного, ASP.NET сияет в этом: - TDD. Код не поддается проверке, сказал Нафф.

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

• Исходя из другого места: Мой опыт - CakePHP и Ruby on Rails. Итак, ясно, в чем моя предвзятость. Речь идет просто о том, что вам удобно.

• Кривая обучения: подробнее остановимся на последнем пункте; Мне не нравилась идея «шаблонов» для изменения функциональности различных элементов. Мне не нравился тот факт, что большая часть дизайна была реализована в коде файла. Это было еще одно, что нужно было узнать, когда я был уже близко знаком с HTML и CSS. Если я хочу сделать что-то в «элементе» на странице, я вставляю «div» или «span», прикрепляю к нему идентификатор и готовлюсь. В веб-формах мне пришлось бы исследовать, как это сделать.

• Текущее состояние веб-дизайна: библиотеки Javascript, такие как jQuery, становятся все более обычным явлением. То, как Web Forms искажает ваши идентификаторы, просто усложняет реализацию (за пределами Visual Studio).

• Больше разделения (дизайн): поскольку большая часть дизайна встроена в ваши элементы управления, это будет очень сложно для внешнего дизайнера. (без веб-форм) знание работы над проектом веб-форм. Веб-формы были созданы для того, чтобы быть всем и всем.

Опять же, большая часть этих причин проистекает из моего незнания веб-форм. Проект веб-форм (если он правильно спроектирован) может иметь «большинство» преимуществ ASP.NET MVC. Но это нюанс: «Если правильно спроектирован». И это просто то, что я не знаю, как делать в веб-формах.

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

В принципе, , сделайте быстрый обзор обоих (попробуйте найти беспристрастный источник [удачи]) со списком плюсов и минусов, оцените, какой из них соответствует вашим целям, и выберите на основе этого.

Итог, выберите путь наименьшего сопротивление и максимальную пользу для достижения ваших целей. Веб-формы - это очень зрелая среда, и в будущем она будет только улучшаться. ASP.NET MVC - просто еще одна альтернатива (для использования Ruby on Rails и разработчиков CakePHP, таких как я: P)

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

В основном, , сделайте быстрый обзор обоих (попробуйте найти беспристрастный источник [удачи]) со списком плюсов и минусов, оцените, какой из них соответствует вашим целям, и выберите, исходя из этого.

Итог, выберите путь наименьшего сопротивление и максимальную пользу для достижения ваших целей. Веб-формы - это очень зрелая среда, и в будущем она будет только улучшаться. ASP.NET MVC - просто еще одна альтернатива (для использования Ruby on Rails и разработчиков CakePHP, таких как я: P)

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

В принципе, , сделайте быстрый обзор обоих (попробуйте найти беспристрастный источник [удачи]) со списком плюсов и минусов, оцените, какой из них соответствует вашим целям, и выберите, исходя из этого.

Итог, выберите путь наименьшего сопротивление и максимальную пользу для достижения ваших целей. Веб-формы - это очень зрелая среда, и в будущем она будет только улучшаться. ASP.NET MVC - просто еще одна альтернатива (для использования Ruby on Rails и разработчиков CakePHP, таких как я: P)

Если вы отлично работаете в веб-формах, вы эффективны, и это работает на вас, вот где вы должны оставаться.

В общем, сделайте быстрый обзор обоих (попробуйте найти беспристрастный источник [удачи]) со списком плюсов и минусов, оцените, какой из них соответствует вашим целям, и выберите, исходя из этого.

Итог, выберите путь наименьшего сопротивления и наибольшую выгоду для удовлетворения ваших цели. Веб-формы - это очень зрелая среда, и в будущем она будет только улучшаться. ASP.NET MVC - просто еще одна альтернатива (для использования Ruby on Rails и разработчиков CakePHP, таких как я: P)

Если вы отлично работаете в веб-формах, вы эффективны, и это работает для вас, вот где вам следует остановиться.

В общем, сделайте быстрый обзор обоих (попробуйте найти непредвзятый источник [удачи]) со списком плюсов и минусов, оцените, какой из них соответствует вашим целям, и выберите, исходя из этого.

Итог, выберите путь наименьшего сопротивления и наибольшую выгоду для достижения ваших целей. цели. Веб-формы - это очень зрелая среда, и в будущем она будет только улучшаться. ASP.NET MVC - просто еще одна альтернатива (для использования Ruby on Rails и разработчиков CakePHP, таких как я: P)

Итог, выберите путь наименьшего сопротивления и наиболее выгодно для достижения ваших целей. Веб-формы - это очень зрелая среда, и в будущем она будет только улучшаться. ASP.NET MVC - просто еще одна альтернатива (для использования Ruby on Rails и разработчиков CakePHP, таких как я: P)

Итог, выберите путь наименьшего сопротивления и максимально выгодно для достижения ваших целей. Веб-формы - это очень зрелая среда, и в будущем она будет только улучшаться. ASP.NET MVC - просто еще одна альтернатива (для использования Ruby on Rails и разработчиков CakePHP, таких как я: P)

Я надеялся увидеть пост из Фила Хаака, но это не было здесь, поэтому я просто вырезал и вставил его от http://blog.wekeroad.com/blog/i-ssome-hill-just-say-it-you-should- learn-mvc/ в разделе комментариев

Haacked - 23 апреля 2009 - Роб, ты бунт! :) Я нахожу это забавно, когда люди пишут спагетти код в MVC, а затем сказать «Смотри! Спагетти!» Эй, я могу написать код спагетти в веб-формах тоже! Я могу написать это в Rails, PHP, Java, JavaScript, но не Lisp. Но только потому, что я не могу ничего не написать в Lisp. И когда я пишу код спагетти, я не смотрю на мою тарелку, стремясь, ожидая увидеть Macaroni. Точка, которые люди часто делают при сравнении его с классическим ASP состоит в том, что с классическими людьми ASP имели тенденцию смешать проблемы. Страницы будут иметь возможность просмотра логики с обработкой ввода пользователей, смешанным с помощью моделей кода и бизнес-логикой все перемешиваются в одном. Это то, о чем спагетти! Смешивание касается всех в одном большом беспорядке. С помощью ASP.NET MVC, если вы следуете за рисунком, вы менее склонны сделать это. Да, у вас все еще может быть немного кода по вашему мнению, но, надеюсь, это все код просмотра. Шаблон побуждает вас не поместить там ваш код взаимодействия пользователя. Положите его в контроллер. Поместите свой модельный код в класс модели. Там. Нет спагетти. Теперь это о-торо суши. :)