ASP.NET MVC Framework – ставим точки

[@woworks]

Начал изучать ASP.NET MVC. Теперь прочитал «Почему вам не нужен MVC Framework» и тут оказывается — он мне не нужен… я в замешательстве…

[@aavezel]

MVC Framework вам нужен потому что вы хотите покрыть юнит-тестами значительную или всю часть кода

Тут не соглашусь. При использовании MVC в «классическом» Asp.Net у вас есть возможность покрыть Unit тестами все модели, и даже вынести их из проекта сделав независимой сутью… Проблема только в том что в «классическом» очень сложно следовать этой парадигме.

[@XaocCPS]

согласен

>> Проблема только в том что в «классическом» очень сложно следовать этой парадигме.

об этом, собственно, и речь

[@VasilioRuzanni]

Почему сложно? Используйте принципы DDD (Domain Driven Design), сделав приложение ASP.NET чисто прикладным приложением, использующим вашу Domain-модель.
Хотя тут нельзя не сказать, что ASP.NET MVC в данном случае лучше подходит, поскольку позволяет нормально тестировать еще и использование вашей домэйн-модели в контексте приложения.
Но в обоих случаях, сама модель, созданная по принципам DDD, не будет «более сложной в следовании парадигме тестирования».

[@Vladek]

И если использовать Passive View с обычным ASP.NET-сайтом, когда приложение общается со страницами через интерфейсы и события, то code-behind страниц становится практически пустым, там остаётся только код привязки данных к контролам. Всей остальной работой занимаются контроллёры страниц, которые-то как раз и обкладываются тестами. Контроллёры, в свою очередь, тоже отделены от сервисного и конфигурационного слоёв, модели предметной области и слоя доступа к данным.

ASP.NET MVC из описанного реализует как раз два слоя — Presentation (Views в их терминологии) и Application (Controllers у них), модель предметной области присутствует номинально, только как название.

[@mezastel]

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

[@acerv]

Извините, но вы профан. Вы просто не понимаете того, о чем вы говорите.

[@nodir]

да, профан…
То, что Вы выбрали или указали в визуальном редакторе, в большинстве случаев будет отображено в разметке Asp.Net контрола

[@CriggerMarg]

настоящие сайты на ASP.Net пишутся без визуального редактора.

[@XaocCPS]

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

[@name1ess0ne]

По поводу перехода ясно, а вот стоит ли начинать изучение с APS.NET MVC? Мне он кажется более понятным и более легким в освоении.

[@XaocCPS]

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

[@lunardust]

Абсолютно не согласен. Считаю, что нет никакой необходимости изучать Web Forms перед там, как браться за MVC, поскольку это альтернативные фреймворки, идеологически не имеющие ничего общего. Уникальные для Web Forms нововведения никаким образом не касаются MVC фреймворка.

[@aavezel]

Если вы до этого использовали PHP + CI(или т.п.), то MVC для вас будет проще в понимании. Если же до этого вы были GUI'стом, то начинать стоит с классики, будет намного проще…

[@name1ess0ne]

Я до этого был гуистом на C#, а в вебе использовал php, но с вебом вообще мало дела имел.
Не знаю почему но мне кажется mvc проще и понятнее, хотя я и его и webforms знаю на одинаковом уровне, уровне начинающего.

[@ashmind]

Да, стоит начинать с MVC и, в общем, на нём и остановится.
Он гораздо проще, понятнее и предсказуемее.

Я даю студентам только его.

[@name1ess0ne]

Спасибо, хотя я уже не студент ) Думаю придется выучить и то и другое, если будет время. Но пока мне нравится MVC.

[@acerv]

Круто%) Мне вот нужен был asp.net mvc, чтобы его можно было сынтегрировать с юнити. А это в свою очередь нужно для черных ящиков, которые пишут разные люди:)

[@XaocCPS]

до unity еще дойдем :)

[@acerv]

Самое зло в жизненном цикле объектов:)

[@sse]

Дык page и handler factory можно было и к классичечкому ASPNET приделать, разве нет?

[@acerv]

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

[@VasilioRuzanni]

По сути, это было бы отдаленной собственной реализацией MVC-Framework. Мы это и сделали еще до появления MVC от MS.

[@chaliy]

Судя по всему, у вас понимание паттерна MVC слегка отличается от общепринятого. Вы бы не могли по-подробней рассказать как это использование DI превращает в «отдаленной реализацией MVC-Framework»?

[@dunkan_macleod]

Спасибо, очень адекватно.

Ато надоели все эти вопли про «viewstate is evil» и прочую дребедень. Дошли даже до того, что и codebehind теперь «evil». Люди начинают забывать в чем была крутизна WebForms как только они появились, и многие не понимают что сильные стороны WebForms абсолютно актуальны и сейчас. Вся критика на самом деле из-за незнания инструмента, с которым работаешь.

Адекватно и взвешенно, побольше бы таких постов.

[@egorinsk]

В чем сила то? В дурной идее сымитировать поведение десктопного приложения? Прпи том что сегодня, наоборот, даже десктопные программы могут делаться на MVC. А все эти viewstate, и прости господи, визуальный редактор веб-страниц — кошмар разработчикаЮ, имхо.

[@dmx]

Простая задача: сделать редактор сущностей, которые можно фильтровать по определенному критерию и выводить постранично.

Первый способ: MVC и хелперы.
Второй на WebFroms с использованием ListView, DataPager и DropDownList для фильтрации. Как думаете, где решение лучше получится и быстрее?

[@ashmind]

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

[@egorinsk]

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

[@VasilioRuzanni]

Если вы не заморачиваетесь с тестированием — то второй метод быстрее. Он еще и проверенный. Но если используете DDD, то MVC уже удобнее, так как все равно код писать.

[@chaliy]

Вы кроме DDD и MVC, еще слово DSL слышали? Так вот ListView, DataPager и DropDownList это все DSL. Который априори юнит тестить смысла не имеет. Вы же, простите за скрытые намеки, не юнит тестите web.config?

[@smilegs]

MVC мне нужен для того, для чего он не нужен вам ))
вообще очень удобная платформа, нет ничего лишнего.
жду продолжения цикла )

[@Dmitry_P]

Полностью согласен с пунктами «за» и «против». Именно эти три пункта «за» являются преимуществами ASP.NET MVC перед классическим ASP.NET. Остальные черты MVC фреймворка, как то паттерн MVC, полный контроль над HTML, отсутствие ViewState, PostBack'ов и событий, красивые URL адреса — не более, чем черты, но не преимущества.

В частности, полный контроль над HTML — на мой взгляд преувеличение. «Неполный» контроль в классическом ASP.NET объясняется использованием серверных web-контролов, которые рендерят сомнительный по качеству HTML. Не используйте их или используйте свои web-контролы, и будет «полный» контроль.

До тех пор, пока в ASP.NET MVC используются несложные хэлперы для генерации HTML, с чистотой кода все ОК. Но как только появятся control suites от DevExpress и прочих, контроль над кодом точно так же потеряется.

[@Ordos]

К тому же красивые URL адреса от mvc и в winforms отлично работают

[@XaocCPS]

кстати, спасибо, напомнили, я про URL тоже хотел написать, но забыл

Обновил статью:

* вам не нужен MVC Framework, если вы хотите получить удобочитаемые URL. Механизм маршрутизации, который позволяет представлять удобочитаемые URL является частью ASP.NET, но не внутренней частью MVC Framework, поэтому использовать маршрутизацию и создавать удобочитаемые URL-ы вы можете и в классическом ASP.NET, MVC Framework для этого вам не нужен.

[@Smerig]

ну опечатался человек :) понятно, что вебформс

[@Zitrix]

> Не используйте их или используйте свои web-контролы, и будет «полный» контроль.
И вот тут две трети программеров начинают выть и стучать ногами по полу: «Не хочу, не буду!» — под миллиардом предлогов: «А это в чужом коде зашито», «А это долго», «А что плохого в форме на весь body?», «А тут просто не получится», «А это и так должно верстаться», «А тут надо много переписывать», «А тут логика не позволяет»…

[@dmx]

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

[@Zitrix]

Безусловно. Только, по факту, наличие готовых решений в .net выливается в перемалывание нелепой верстки. А это уже мое время, с которого не будет ни знаний, ни строчки в резюме. Уж лучше бы этой альтернативы не было :)

[@Ordos]

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

[@XaocCPS]

я не могу знать какие вы делали проекты и как в них связывались javascript и web forms, но мой опыт говорит мне, что работа с автогенерируемыми идентификаторами пользовательских элементов управления через javascript — это трудозатраное дело. Втыкать всюду в коде скрита вставки с ClientId — это не айс, как не крути.

[@ennui]

Можно использовать селекторы не только по id, а например по class. Ну и в крайнем случае, задавать ивенты элементам inline.

[@XaocCPS]

выкрутиться всегда можно, речь не об этом, в MVC это делать просто не нужно

[@Ordos]

Меня немного пугает, полный контроль над id. Если я например помещу на страницу селект со списком производителей, и хочу чтобы при выборе производителя у меня производилась фильтрация по нему (фактически перенаправление на другую страницу), то используя серверный селект и используя вставку с ClientID я уберегу себя от случайного размещения контрола с таким же id (например VendorList, ну мало ли приспичит вставить).

[@Smerig]

я в нашем проекте пошел другим путем. Выцеплял значение контролов из постбека путем добавления к их имени этих всяких id separator.

Решение, конечно, не айс, но вот пример:

String prefix = elements.NamingContainer.UniqueID + ((PaymentFillControl)(this)).IdSeparator.ToString();

А потом доставал значение:

val = Utils.GetParamValue(Request, prefix + _fpc[i].ControlName);

[@Smerig]

хотя тут вроде не о том совсем :) извиняюсь

[@Ordos]

С первым действительно нет проблем)
А вот что такое динамический и статический рендеринг?

[@ozlev]

Чудно…
Всё время пытался сказать эти за и против, но никак не доходили руки конкретизировать…

[@linin]

Интересующим порекомендовал «погуглить» в рунете, в торрентах: Разработка веб-приложений с использованием ASP.NET MVC Framework Автор: Гайдар Магдануров. Это видео с зимних мастер-классов в московском офисе Microsoft. В частности, Гайдар высказался на тему этого топика: чем интересен ASP.NET MVC

[@XaocCPS]

гуглить не надо, наверняка, все эти ведео есть на techdays.ru

[@linin]

Есть и не только там. Просто я прямые ссылки не хотел пиарить. Также есть и на популярных торрент-треккерах. Ищущий всегда найдет.

[@ennui]

>Времена поменялись, меняется и классический ASP.NET, в нем есть множество инструментов по поддержке AJAX-функционала.
AJAX, реализованный стандартными средствами ASP.NET не юзабелен и его лучше вообще не трогать пока AJAX ASP.NET 4.0 не выйдет.

«за» и «против» написанные тут, личное мнение, основанное на личном опыте. Согласен только в одном, что MVC не лекарство от кривых рук. И переходить с чего-то на что-то тоже не выход. Тут больше надо смотреть на задачу, и исходя из задачи использовать ту или иную платформу.

Но, если ты хочешь увидеть зелёный цвет в W3C валидаторе, используй MVC.

[@Dmitry_P]

>Но, если ты хочешь увидеть зелёный цвет в W3C валидаторе, используй MVC.

Только до тех пор, пока весь код пишется вручную или генерируется проверенными хэлперами

[@ennui]

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

[@Dmitry_P]

Насколько я знаю про известных разработчиков UI, сейчас контролы под ASP.NET MVC есть только у Syncfusion — www.syncfusion.com/Products/aspnet-mvc. Я имею ввиду контролы, соответствующие идеологии ASP.NET MVC, т.е. генерирующие код через хэлперы, а не серверные web-контролы, адаптированные под MVC. У Telerik, например, есть именно такие.

[@Dmitry_P]

>Но, если ты хочешь увидеть зелёный цвет в W3C валидаторе, используй MVC.

Только до тех пор, пока весь код пишется вручную или генерируется проверенными хэлперами

[@AlekseyNemiro]

> Но, если ты хочешь увидеть зелёный цвет в W3C валидаторе, используй MVC.

В WebForm это не проблема, был у меня как-то простенький сайтец с зелеными валидаторами.

[@dmx]

Да и не только простенький можно сделать валидным, было бы желание.
Как-то занимался вопросом, захотелось в этом поупражняться — все получилось. А написать кривого кода можно и в MVC. WebForms — это ведь не только Menu и GridView.

[@ennui]

Как то за всё время Menu ни разу не пришлось использовать…

Как я уже говорил надо рассматривать саму задачу. И использовать то или иное, или всё вместе (часто приходится писать сам сайт на MVC, а админку на WebForms).Скорость генерации разметки на MVC >> чем на WebForms.
У MVC хватает своих минусов: нет инструментария WebForms (трэйсинг например) или output кэш не такой гибкий (нет подстановки в кэш).

[@dieron]

>AJAX, реализованный стандартными средствами ASP.NET не юзабелен и его лучше вообще не трогать пока AJAX ASP.NET 4.0 не выйдет

Зато этот AJAX прикручивается к простенькой формочке за 2 минуты.

И почему он не юзабелен?

[@ennui]

Потому что простейшая задача, например проверки существования введённого имени. Ведёт к тому что на серверной стороне, помимо того что будет выполнен запрос к БД на проверку существования пользователя, будет по новому сгенерировна вся страница, потом страница отошлётся пользователю и JS на пользовательской стороне обновит только блок находящийся в UpdatePanel. И это только раде того что бы узнать«есть такой пользователь или нет?».

Да, зато это можно сделать быстро стандартными средствами ASP.NET AJAX, но я лучше напишу веб сервис, и используя, какой либо js фрэймворк сделаю ajax запрос к этому веб сервису.

[@XaocCPS]

ASP.NET AJAX красиво работает с web-сервисами, еще лучше чем с update panel

[@ennui]

С web-сервисами, красиво работает ToolKit, но не стандартный набор ASP.NET AJAX 2.
А вот версия ASP.NET AJAX 4, красиво работает с web-сервисами и web-методами.

[@VasilioRuzanni]

Ну тот же jQuery и ExtJS не менее (если не более) прекрасно работают с веб-сервисами.

[@Ordos]

Вы хотите тотальной оптимизации. Это плохой повод говорить, что asp.net ajax невозможно использовать.
Если правильно им пользоваться, то обработка ajax-запросов будет выполняться без задержек, а, как говориться, если нет разницы…

[@butaji]

Отличная подборка аргументов за и против.
От себя хотелось бы сказать следующее: в последнее время я очень сильно увлекся Ruby веб-стеком Ruby On Rails/Merb (очень жду Rails3), по сравнению с этой платформой (именно платформой, а не каркасом), ASP.NET MVC пока немного неуклюж и не элегантен. Но в связи с тем, что .NET — основная моя платформа, и у меня пока нет острой необходимости в работе с ASP.NET MVC, я буду смотреть в сторону стека IronRuby on Rails, где получу максимум интеграции и максимум элегантности и легкости решений

[@VasilioRuzanni]

«вам не нужен MVC Framework, если вы считаете, что он лучше классического ASP.NET…… Переходить на новый фреймворк просто неоткуда, если у вас нет должного понимания и любви к базовому механизму. Изучить ASP.NET, поймите почему и как там все устроено. MVC Framework вам не нужен»

Очень уж субъективно. Сравнивается, как я понял ASP.NET WebForms и ASP.NET MVC? Ибо и то, и другое — ASP.NET. У каждой технологии своя концепция. И что значит переходить неоткуда? А если команда начинает использовать ASP.NET, до этого используя RoR, Django, CakePHP и так далее?
Для того, чтобы успешно использовать ASP.NET MVC, далеко не обязательно знать концепцию WebForms.

А ASP.NET — это просто «движок», «runtime», и WebForms с MVC его только используют для своих целей.

[@lunardust]

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

[@ilinsky]

MVC архитектурный шаблон красив на первый взгляд. И он действительно работает в простых задачах. Однако про попытке воспользоваться им при разработке более-менее сложных приложений быстро упираешься в проблему — код становится малоуправляемым и его действительно сложно эффективно раширять. Для решения данной проблемы в свое время были сделаны 2 независимых предложения: hMVC и PAC. Настоятельно рекоммендую посмотреть в их сторону. Есть неплохая статья про PAC например здесь: www.dossier-andreas.net/software_architecture/pac.html

[@Crypto]

Согласен с каждым пунктом из раздела «Почему вам НЕ нужен MVC Framework», во втором разделе очевидным является лишь пункт про юнит тесты.

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

[@XaocCPS]

мне известны проекты по созданию helper-методов для MVC-версии Grid, есть очень мощные проекты по созданию альтернативных view engine, в том числе например на базе ironruby (проект Spark). Правда, это некоммерческие проекты, но ничего не мешает развивать в эту сторону проекты в коммерческом плане.

[@nimnull]

есть оч. хорошая библиотека MvcContrib (codeplex) которая решает кучу проблем с гридами, их пейджингом и приносит много минут радости и счастья разработчику, а еще очень хорошие вещи находятся в ASP.NET MVC Futures. MVC как-бы хорош при использовании бэкенда в виде DataClasses или DataEntities, когда классический WebForms и его библиотека контролов предполагает работу с DataSet.

[@VasilioRuzanni]

А как напрямую связаны MVC и «DataClasses или DataEntities»?

[@nimnull]

речь шла о ASP.NET MVC Framework, если внимательно следить за таймлайном развития фреймворка и блогами разработчиков сего чуда, то можно про себя и вслух отметить то, с какой любовью они продвигают их, применительно к DAL приложений на mvc framework.

[@VasilioRuzanni]

О том и речь, что MVC Framework — это каркас приложения в веб-контексте, а с DAL этот каркас никак не связан напрямую. Можно сказать, что буква M — весьма условное понятие в ASP.NET MVC. В нем нет никаких механизмов, классов и фреймворков для Domain Modeling, чтобы получить те самые «Data Classes и Data Entities». Так что вопрос того, что вместе с MVC использовать на уровнях BLL и DAL — прерогатива разработчиков конкретного прикладного решения или проекта.

[@dieron]

Отличные примеры «за» и «против». Согласен со всеми аргументами.

Я бы еще добавил, что MVC Framework и классический ASP.NET хороши для различного типа задач.

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

Но, например, большая на 3-4 страницы форма ввода данных на MVC — это мазохизм, хотя и реально реализуемо. Тут лучше использовать ASP.NET с валидаторами, ViewState и т.д.

Еще мне очень нравится тот темплейт, который устанавливается в студию вместе с MVC — для маленького проектика на 8 часов именно то, что нужно. Быстрый старт, так сказать.

[@sse]

Еще один «за» для MVC — в случае использования другого движка рендеринга страниц: напр., Velocity или XSLT. Это как раз хороший пример расширяемости.

[@ashmind]

Не очень убедительно.

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

Хорошо, и в чём же прелесть? На мой взгляд, чем больше изучаешь ASP.NET, тем яснее видно что MVC лучше.

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

Да, я могу взять monorail, который требует изучить новый template language и доказать заказчику что эта 3rd party библиотека очень нужна на проекте. Или я могу взять ASP.NET MVC, с документацией и дизайном от MS и с привычным языком разметки.

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

вам не нужен MVC Framework, если вы хотите “получить полный контроль над разметкой“

Да, я могу создать свои control adapters для стандартных menu, etc. Я могу писать контолы красиво и аккуратно. Или я могу взять ASP.NET MVC и html буду знать не только я, а ещё и вся команда.

[@Al_Kash]

Есть ли люди, которые после 'серьезной' работы со структурой приложения MVC, вернулись к предыдущей?

На мой взгляд обратной дороги нет! ))

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

Я считаю это утверждение (как и большинство остальных) говорит о малом опыте работы с MVC.

[@sirmakc]

Дает ли классический ASP.NET полное разделение разработки на server side и client side?

ASP.NET MVC дает. При работе с ним есть все возможности развести две команды по углам и дать им трудиться совершенно раздельно(согласуя форматы данных)

[@chaliy]

А можно примерчик по конкрейтней. А то я не вижу это проблемы для ASP.NET.

[@hannimed]

Судя по коментам, не далек тот день, когда начнутся холивары между разработчиками на ASP.NET Forms и ASP.NET MVC…

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

[@dieron]

Поддерживаю замечание по скорости разработки. MVC требует больше времени на реализацию одной и той же (усредненной) задачи, хотя в перспективе, возможно, упростит внесение изменений в существующий продукт.

[@sirmakc]

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

[@Ordos]

Да, об этом можно будет и кино снять: «Давным-давно разработчики asp.net были едины и вместе сдерживали нападения php-программистов, но потом произошел Великий Раскол и началась война...» :o)

[@ashmind]

MVC проигрывает в скорости разработки? Почему? На мой взгляд наоборот практически всё получается быстрее.
Единственное что будет медленнее, это очень навороченный грид, но тогда я в любом случае возьму Flexigrid, например.

[@hannimed]

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

[@ashmind]

Ну не час на ASP.NET, даже если использовать Dynamic Data.
К тому же это такой идеальный сайт, прямо из примера на Dynamic Data, в жизни обычно есть куча особенностей.

Но даже если так, aspnet_User и прочий default membership довольно по дурацки выглядит в базе и потенциально неудобен.
Большая форма с некоторой ловкостью рук пишется за 10 мин (foreach… GetType().GetProperties()), Model Binder.
Табличные данные — это да, но я возьму готовую AJAX таблицу и всё ещё и быстрее будет.

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

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

[@hannimed]

Час, минут 30 даже… А страницы и так не большие и быстро грузятся… Учите ASP.NET :)

Про готовый и отлаженный и испытанный в самых жёстких боевых условиях Membership — это отдельный разговор.

[@ashmind]

Было бы забавно сделать видео — полчаса на сайт на ASP.NET.

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

Кстати, на мой взгляд, то что в ASP.NET можно учить (lifecycle, ashx, modules, services, state, health monitoring, cache) как раз выходит за рамки получасовой задачи. :)

[@hannimed]

Учить — да, соглашусь. Но если это всё знать, то это очень ускоряет разработку. Тот же AJAX: WebServices + scriptManager — дело 5 секунд, и уже готовый кроссбраузерный AJAX без всяких UpdatePanels…

[@ifa]

Вопрос к автору — почему для вашего сайта Вы использовали движок KIGG, который и реализован с помощью ASP.NET MVC?

[@Ordos]

Наверняка, чтобы освоить технологию.

[@Illorian]

Для меня MVC — решение многих проблемы, которые были на php