ASP.NET MVC напоминает мне о старом Классике запутанный код ASP

Это было упомянуто в PDC, они действительно упоминали, что это было немного также "классического asp" как со всем < % =. Но они также упоминали, что будут добавлять стандартные метки ASP.NET и средства управления.

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

Видео PDC: http://mschnlnine.vo.llnwd.net/d1/pdc08/WMV-HQ/PC21.wmv

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

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

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

Напротив, смотрите на движок шаблонов Django . В платформе Django контроллеры и модели записаны с помощью полноценного языка Python, но движок шаблонов представления определяет ограниченный язык , который только обеспечивает основные конструкции программирования (условное выражение, циклы, и т.д.). Этот ограниченный язык напоминает Python, но это не на самом деле Python, таким образом, это не может вызвать произвольный код как внешние библиотеки. Это может только получить доступ к данным модели, который передается в представлению.

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

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

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

РЕДАКТИРОВАНИЕ : Я забыл упоминать способность создать методы расширения HtmlHelper, который позволяет Вам переместить много материала в бэкенд также. В целом, между контроллерами, моделями и дополнительными методами это составляет в целом намного больше кода, который является легко тестируемым в MVC это или в классическом ASP или в ASP.NET WebForms.

Finlay Microsoft исправляет свою ошибку с Классиком ASP к шагу ASP.NET. 70% старых программистов asp перешли к PHP, потому что ASP.NET был к комплексу.

Они жесткий, что все может быть решено с препаратом ASP.NET и меню отбрасывания. И в конце все внутреннее форма тег! Мы создаем большую "веб-форму" не веб-сайты. Только посмотрите на HTML от любого сайта ASP.NET. Абсолютно ужасный!

ASP.NET MVC является новой НАДЕЖДОЙ на инструмент для очистки более организованный код HTML и мощная бизнес-логика.

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

Классический ASP был механической коробкой передач только со вторым механизмом.

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

Согласно блог Scott Guthrie:

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

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

Примеры альтернативных механизмов Представления , NHaml обсудил здесь , , Spark обсудил здесь и , NVelocity обсудил здесь .

Проверьте механизм представления StringTemplate, это выглядит хорошим и чистым.

Потому что людям, стоящим за MVC, действительно нравятся страницы ASP / JSP, и они хотят реализовать их заново. Похоже, они ненавидят:

• ViewState
• Существующие элементы управления ASP.Net
• Очистить HTML
• Существующие элементы управления пользователем
• Постбэки

Похоже, они любят:

• Повторное изобретение колеса
• ] REST-полные URL-адреса

MVC по сути является способом принудительного отделения кода от представления. Если бы разработчик действительно позаботился, этого можно было бы легко достичь с помощью обычного Asp.Net. В любом случае можно панкнуть всю систему "разделения", так что я не вижу в этом смысла.

Тем не менее, в этом есть некоторые достоинства ... но их недостаточно, чтобы перевесить проблемы. MVC версии 3, я уверен, будет потрясающе.

И прежде чем кто-нибудь поставит мне оценку -1, посмотрите, на сколько вопросов MVC я ответил. Я знаю, о чем говорю. Если вы серьезно относитесь к своему разлуке, взглянув на него, вы поймете, что chaiguy1337 - это хорошо. Шаблон String выглядит великолепно , потому что он не позволяет использовать какой-либо код в вашем интерфейсе! На мой взгляд, команда ASP.net MVC проиграла MVC.

В классическом ASP у вас не было выбора перенести бизнес-логику из уровня пользовательского интерфейса. В ASP.Net MVC код «спагетти» изолирован от уровня пользовательского интерфейса, представления; 90% вашей логики будет в слоях «M» и «C», которые являются обычными, не спагетти-классами C #

Представление задумано как «тупое». Ничего критичного с точки зрения бизнес-логики. Он предназначен, чтобы быть почти одноразовым.

Вы можете неаккуратно покрасить комнату, не повредив структуру. Если вы решили очистить его и перекрасить, не нужно вызывать архитектора. То же самое с View.

После программирования MVC на некоторое время я возвращаюсь к ASP.NET.

MVC действительно хороший шаг вперед по сравнению с классическими ASP или PHP, но это большой шаг назад по сравнению с ASP.NET.

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

У технологии есть свои достоинства, но она еще не разработана.

Может быть, в версии 3.0 ...