ASP.NET MVC напоминает мне старый классический ASP-спагетти код

Ответ 1

см. сообщение Джеффа (http://www.codinghorror.com/blog/archives/001155.html), который повторяет ваш вопрос, и ответ Роба Конье (http://blog.wekeroad.com/blog/asp-net-mvc-avoiding-tag-soup/)

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

Ответ 2

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

По Блог Скотта Гатри:

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

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

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

Ответ 3

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

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

ASP.NET MVC - это новый HOPE для более организованного HTML-кода и мощной бизнес-логики.

Ответ 4

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

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

Ответ 5

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

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

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

Ответ 6

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

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

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

Ответ 7

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

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

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

Технология заслуживает этого, но пока еще не созрела.

Возможно, в версии 3.0...

Ответ 8

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

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

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

Ответ 9

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

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

Ответ 10

Посмотрите StringTemplate, он выглядит красиво и чисто.

Ответ 11

Я всегда удивляюсь отсутствию понимания дизайна n-layer/level, продемонстрированного некоторыми из самых громких сторонников asp.net mvc. SOC всегда достижимо в веб-формах. Паттерны пользовательского интерфейса, такие как MVP, всегда были доступны в веб-формах. Это не ошибка платформ, которые многие разработчики не умеют разрабатывать.

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

Personaly, я предпочитаю шаблон MVP поверх MVC.

Ответ 12

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

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

Они, кажется, любят:

• Повторное изобретательство колеса
• REST-ful urls

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

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

И прежде чем кто-нибудь отметит меня в -1, посмотрите, сколько вопросов MVC я ответил. Я знаю, о чем говорю.

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

Ответ 13

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

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

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

Ответ 14

Для записи:

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

Общие веб-сайты полагаются на full-form-post/get и в AJAX, если вы используете оба, то вы превращаете "C" из MVC в беспорядок.

В конечном счете, большинство программистов заканчивают "обманывать", помещая вызов ajax в слой VIEW.