Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 46
можно линк на оригинал?
спасибо
спасибо
Никаких статиков, используйте какой-нибудь BaseController или MasterController.
А вскоре в MVC по словам Скотта Гатри появится реализация концепта SubController-ов, отвечающих за отдельные части страницы. Пока же можно использовать BaseController и фичу RenderPartial.
А вскоре в MVC по словам Скотта Гатри появится реализация концепта SubController-ов, отвечающих за отдельные части страницы. Пока же можно использовать BaseController и фичу RenderPartial.
> RenderAction убрали в версии Beta
Зато появился RenderPartial
Зато появился RenderPartial
Всё-таки удобно объеденять какие-то корпоративные решения в DLL. Накапливать их и документировать, а потом приятно делиться с начинающими… Жаль этот момент упущен в ASP.NET MVC…
Да, так сейчас и есть, но я склонен думать, что это все-таки вопрос времени, ведь MVC сейчас еще очень сырая в то время как WebForms уже столько лет и она уже очень стабильна.
Да, кстати, я говорил про MVC в целом — а что касается DLL — чем именно мешает ASP.NET MVC?
Как вы умудрились нарисовать такую простую блок-схему таким сложным образом? Нафига столько пересечений линий?
И как вообще связи между узлами могут разветвляться? Вроде бы всегда рисовали Узел>Решение>Связь>Узел>…
Это вообще мелочь, конечно, но заставляет задуматься как вообще люди пришли к такому решению как ASP.NET WebForms с его ущербным ViewState.
Видимо, эти люди просто мыслят в другом ракурсе, мне их просто не понять. Не скажу что это плохо, просто назову это «эзотерическим программированием».
И как вообще связи между узлами могут разветвляться? Вроде бы всегда рисовали Узел>Решение>Связь>Узел>…
Это вообще мелочь, конечно, но заставляет задуматься как вообще люди пришли к такому решению как ASP.NET WebForms с его ущербным ViewState.
Видимо, эти люди просто мыслят в другом ракурсе, мне их просто не понять. Не скажу что это плохо, просто назову это «эзотерическим программированием».
Схему рисовал, слава богу, не я :) Я ее только перевел, но замудренная — это точно.
Насчет ViewState с вами полностью согласен. Попытка ввести состояния там, где их по определению не должно быть (впрочем, попытка, чего уж там, успешная — ведь очень распространен WebForms).
Однако, не согласен насчет того, что WebForms — неверное решение. Вполне рабочее. Хотя мне, в любом случае и ближе MVC, я прекрасно понимаю, почему был придуман WebForms (особенно с учетом того, когда именно он появился — ведь это уже давно было).
Насчет ViewState с вами полностью согласен. Попытка ввести состояния там, где их по определению не должно быть (впрочем, попытка, чего уж там, успешная — ведь очень распространен WebForms).
Однако, не согласен насчет того, что WebForms — неверное решение. Вполне рабочее. Хотя мне, в любом случае и ближе MVC, я прекрасно понимаю, почему был придуман WebForms (особенно с учетом того, когда именно он появился — ведь это уже давно было).
Не знаю насчет ущербности… Конечно без него можно обойтись, но админка с двумя каскадными GridView и DetailsView на каждую будет уж куда изящнее выглядеть в WebForms, чем в ASP.NET MVC. Все зависит от задач. Да и Viewstate легко можно отключить там где не нужно, ничего ведь не мешает.
Ну, это зависит от реализации. Просто WebForms контрол — наполовину серверный и его события там же обрабатываются, а с MVC мы обычно использовали разные гриды из ExtJS и построенные на JQuery.
Разрабатывать админки — самая простая задача.
Не надо заботиться о совместимости браузеров, о размере страницы в Кб, и прочих подобных вещах.
Т.к. людей, которые получат доступ к админке (их мало) можно заставить использовать конкретный браузер, да и они обычно на быстром канале или близко к серверу (т.е. количество запросов и объём передаваемых данных роли не играют).
Совсем другое дело — это сделать сайт «для всего мира»
Т.к. людей, которые получат доступ к админке (их мало) можно заставить использовать конкретный браузер, да и они обычно на быстром канале или близко к серверу (т.е. количество запросов и объём передаваемых данных роли не играют).
Совсем другое дело — это сделать сайт «для всего мира»
И тем не менее это не отрицает того, что я сказал ;)
Я не говорю, что это сложно. Но я в процессе разработки пришел к выводу, что фронтенд лучше делать на MVC, а управление всем этим добром на WebForms.
Поверьте, наразрабатывался уже и того и того. И обе технологии имеют как свои достоинства, так и недостатки. Поэтому однозначных выводов делать нельзя, все зависит от проекта, а то и отдельных его частей.
Я не говорю, что это сложно. Но я в процессе разработки пришел к выводу, что фронтенд лучше делать на MVC, а управление всем этим добром на WebForms.
Поверьте, наразрабатывался уже и того и того. И обе технологии имеют как свои достоинства, так и недостатки. Поэтому однозначных выводов делать нельзя, все зависит от проекта, а то и отдельных его частей.
А вот для клиентских сраниц придётся отключить Viewstate.
И вот тут уже легче будет с Asp.net MVC
В принципе, технологии Webforms можно просчёты списать на возраст. Т.е. когда она разрабатывалась, никто не мог предположить в каком ключе будут развиваться технологии (в данном случае Web).
Не зря же ввели новый подход (MVC) — решать современные задачи быстрее и легче.
ЗЫ. Извините за разрозненные комментарии, нажимаю Ctrl+Enter по привычке
И вот тут уже легче будет с Asp.net MVC
В принципе, технологии Webforms можно просчёты списать на возраст. Т.е. когда она разрабатывалась, никто не мог предположить в каком ключе будут развиваться технологии (в данном случае Web).
Не зря же ввели новый подход (MVC) — решать современные задачи быстрее и легче.
ЗЫ. Извините за разрозненные комментарии, нажимаю Ctrl+Enter по привычке
Я вам уже ответил, в общих чертах :)
PS. За Cntrl + Enter надавал бы сам тому кто придумал. Сделали бы возможность отключать хотя бы. Не чат же тут все-таки.
PS. За Cntrl + Enter надавал бы сам тому кто придумал. Сделали бы возможность отключать хотя бы. Не чат же тут все-таки.
Не столько подход новый (ему уже лет 20), сколько разработчики пришли к осознанию того, что его удобно использовать и в вебе тоже.
Я имел ввиду, что на программирование на ASP чётко ассоциировалось с WebForms (по урайней мере, у меня).
До какого-то времени, пока методология MVC (опять же в ASP) не начала приобретать популярность.
До какого-то времени, пока методология MVC (опять же в ASP) не начала приобретать популярность.
Никто не мешает реализовывать паттерн MVC/MVP используя webforms. Тогда TDD в руки и вперёд. Также даёт полный контроль над архитектурой приложения. Не думаю, что asp.net mvc окажется более гибким. Хотя всё зависит от умения готовить…
Уточните насчет MVC используя WebForms. Зачем?
WebForms реализует паттерн Page Controller, в то время как ASP.NET MVC реализует паттерн Front Controller. Мне всегда казалось, что реализовать Front Controller на ASP.NET возможно, более того, это сделали сначала Castle Project, а теперь еще и Microsoft. WebForms (Page Controller) — это уже надстройка над ASP.NET, причем достаточно «тяжелая». Так зачем использовать ее для реализации куда более легковесной прослойки?
В этом плане MVC куда более гибкий, так как он не использует всю тяжеловесную архитектуру WebForms, а строится «с нуля на голом ASP.NET». Да и зачем реализовывать MVC/MVP на ASP.NET еще как-либо, когда это делает Microsoft и очень успешно.
WebForms реализует паттерн Page Controller, в то время как ASP.NET MVC реализует паттерн Front Controller. Мне всегда казалось, что реализовать Front Controller на ASP.NET возможно, более того, это сделали сначала Castle Project, а теперь еще и Microsoft. WebForms (Page Controller) — это уже надстройка над ASP.NET, причем достаточно «тяжелая». Так зачем использовать ее для реализации куда более легковесной прослойки?
В этом плане MVC куда более гибкий, так как он не использует всю тяжеловесную архитектуру WebForms, а строится «с нуля на голом ASP.NET». Да и зачем реализовывать MVC/MVP на ASP.NET еще как-либо, когда это делает Microsoft и очень успешно.
На blogs.gotdotnet.ru за последние полгода были горячие дискуссии на эту тему :)
А вот и видеодоклад именно на эту тему на TechDays — www.techdays.ru/Lecture.aspx?LID=b102ed23-f4ff-45f7-9a5a-a0f78efd7719
А вот и видеодоклад именно на эту тему на TechDays — www.techdays.ru/Lecture.aspx?LID=b102ed23-f4ff-45f7-9a5a-a0f78efd7719
Ага, смотрел уже :) Сами между собой в команде сколько спорили с новичками, которые не понимали зачем нам MVC.
извините, а что с TechDays творится? захожу на него, но он меня постоянно забывает… просит заново авторизоваться и я не могу просмотреть большую часть докладов, хотя некоторые просмотреть удается… пробовал и через OpenID и через LiveID авторизоваться, все бестолку… у всех так или только у меня такая проблема?
MVC был придуман в начале 80-х в smalltalk,
в 1996 в книге сейчас известной как GoF был введён шаблон проектирования Observer (Наблюдатель) — более общий случай MVC.
Рассмотрите его: Observer design pattern
в 1996 в книге сейчас известной как GoF был введён шаблон проектирования Observer (Наблюдатель) — более общий случай MVC.
Рассмотрите его: Observer design pattern
Я уже имею опыт использования ASP.NET MVC в коммерческих проектах (начиная с Preview 3).
Лично для меня, помогло во многом упростить и ускорить процесс разработки. До MVC мы и так были вынуждены отказаться от ViewState, поэтому вся автоматизация WebForm полетела в жопу.
Что касается статьи (плюсы минусы технологий):
— ViewState это минус, минус в том, что отключив его перестают полностью работать Postback-и, приходиться все делать самому.
— Для WebForms, сложность верстки, т.к. отсутствует возможность повлиять на код, получаемый в результате.
Лично для меня, помогло во многом упростить и ускорить процесс разработки. До MVC мы и так были вынуждены отказаться от ViewState, поэтому вся автоматизация WebForm полетела в жопу.
Что касается статьи (плюсы минусы технологий):
— ViewState это минус, минус в том, что отключив его перестают полностью работать Postback-и, приходиться все делать самому.
— Для WebForms, сложность верстки, т.к. отсутствует возможность повлиять на код, получаемый в результате.
Сами по себе не завязаны, но, к сожалению, завязаны очень многие компоненты и контролы, которые хранят там свое состояние, с которым работают всякие postback-обработчики. На самом деле странно, что ViewState стал у многих стандартом де-факто. Так, стоп! Кто-то до сих пор использует WebForms? :)
Ну почему же? В MVC есть TempDataDictionary (плюс контракт ITempDataProvider и его дефолтная реализация SessionStateTempDataProvider), а также ModelState, которые как раз для этого. То есть, отнюдь не ручками все.
P.S. WebForms не страшен — он не нужен. Все необходимое «пространство задач» покрывают MVC и WebMatrix.
P.S. WebForms не страшен — он не нужен. Все необходимое «пространство задач» покрывают MVC и WebMatrix.
Работаю с MVC начиная с 1-го preview.
Поначалу был против использования сомнительного фреймворка, тем более preview. Но чем больше писал, тем больше мне нравился ASP.Net MVC. Сейчас не могу смотреть в сторону WebForms, смотрю на это как на тяжеловесный крейсер.
Да админку с нуля проще будет написать используя WebForms, но если у тебя уже есть свой набор жизненно необходимых контролов и helper'ов, сделать админку на ASP.Net MVC не так сложно и долго. Да и не забываем о MVC Toolkit и реализации DynamicData под MVC.
P.S. к минусам WebForms я бы ещё отнёс генерируемый «адский» javascript, пусть то для обычных валидатаров или для ASP.Net AJAX.
Поначалу был против использования сомнительного фреймворка, тем более preview. Но чем больше писал, тем больше мне нравился ASP.Net MVC. Сейчас не могу смотреть в сторону WebForms, смотрю на это как на тяжеловесный крейсер.
Да админку с нуля проще будет написать используя WebForms, но если у тебя уже есть свой набор жизненно необходимых контролов и helper'ов, сделать админку на ASP.Net MVC не так сложно и долго. Да и не забываем о MVC Toolkit и реализации DynamicData под MVC.
P.S. к минусам WebForms я бы ещё отнёс генерируемый «адский» javascript, пусть то для обычных валидатаров или для ASP.Net AJAX.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ASP.NET MVC vs. WebForms