Comments 99
Начал изучать ASP.NET MVC. Теперь прочитал «Почему вам не нужен MVC Framework» и тут оказывается — он мне не нужен… я в замешательстве…
MVC Framework вам нужен потому что вы хотите покрыть юнит-тестами значительную или всю часть кодаТут не соглашусь. При использовании MVC в «классическом» Asp.Net у вас есть возможность покрыть Unit тестами все модели, и даже вынести их из проекта сделав независимой сутью… Проблема только в том что в «классическом» очень сложно следовать этой парадигме.
согласен
>> Проблема только в том что в «классическом» очень сложно следовать этой парадигме.
об этом, собственно, и речь
>> Проблема только в том что в «классическом» очень сложно следовать этой парадигме.
об этом, собственно, и речь
Почему сложно? Используйте принципы DDD (Domain Driven Design), сделав приложение ASP.NET чисто прикладным приложением, использующим вашу Domain-модель.
Хотя тут нельзя не сказать, что ASP.NET MVC в данном случае лучше подходит, поскольку позволяет нормально тестировать еще и использование вашей домэйн-модели в контексте приложения.
Но в обоих случаях, сама модель, созданная по принципам DDD, не будет «более сложной в следовании парадигме тестирования».
Хотя тут нельзя не сказать, что ASP.NET MVC в данном случае лучше подходит, поскольку позволяет нормально тестировать еще и использование вашей домэйн-модели в контексте приложения.
Но в обоих случаях, сама модель, созданная по принципам DDD, не будет «более сложной в следовании парадигме тестирования».
И если использовать Passive View с обычным ASP.NET-сайтом, когда приложение общается со страницами через интерфейсы и события, то code-behind страниц становится практически пустым, там остаётся только код привязки данных к контролам. Всей остальной работой занимаются контроллёры страниц, которые-то как раз и обкладываются тестами. Контроллёры, в свою очередь, тоже отделены от сервисного и конфигурационного слоёв, модели предметной области и слоя доступа к данным.
ASP.NET MVC из описанного реализует как раз два слоя — Presentation (Views в их терминологии) и Application (Controllers у них), модель предметной области присутствует номинально, только как название.
ASP.NET MVC из описанного реализует как раз два слоя — Presentation (Views в их терминологии) и Application (Controllers у них), модель предметной области присутствует номинально, только как название.
Не уверен что согласен с тем, что тут написано. Сам являюсь в ASP.NET скорее начинающим, но, тем не менее, четко вижу разницу между MVC подходом и WebForms. На MVC больше получается, создаю более понятный код, который потом можно читать, в отличии от WebForms где я использовал мудреные настройки контролов визуального редактора которые забываются на следующий день после того как их используешь.
По поводу перехода ясно, а вот стоит ли начинать изучение с APS.NET MVC? Мне он кажется более понятным и более легким в освоении.
нет, не стоит
и хотя каждый идет своим путем, я скажу что изучать надстройку не поняв зачем она была сделана и как работает, чем отличается и для чего применяется по сравнению с базовым функционалом — это плохо. В этом случае мимо вас пройдут и всегда будут проходить нововведения в классический asp.net, приемуществ которого вы не будете понимать. Сформируется ошибочная точка зрения что классический asp.net — это плохой механизм (это уже заметно по некоторым комментариям). Этого нужно избежать, как я считаю.
и хотя каждый идет своим путем, я скажу что изучать надстройку не поняв зачем она была сделана и как работает, чем отличается и для чего применяется по сравнению с базовым функционалом — это плохо. В этом случае мимо вас пройдут и всегда будут проходить нововведения в классический asp.net, приемуществ которого вы не будете понимать. Сформируется ошибочная точка зрения что классический asp.net — это плохой механизм (это уже заметно по некоторым комментариям). Этого нужно избежать, как я считаю.
Если вы до этого использовали PHP + CI(или т.п.), то MVC для вас будет проще в понимании. Если же до этого вы были GUI'стом, то начинать стоит с классики, будет намного проще…
Да, стоит начинать с MVC и, в общем, на нём и остановится.
Он гораздо проще, понятнее и предсказуемее.
Я даю студентам только его.
Он гораздо проще, понятнее и предсказуемее.
Я даю студентам только его.
Круто%) Мне вот нужен был asp.net mvc, чтобы его можно было сынтегрировать с юнити. А это в свою очередь нужно для черных ящиков, которые пишут разные люди:)
до unity еще дойдем :)
Дык page и handler factory можно было и к классичечкому ASPNET приделать, разве нет?
Спасибо, очень адекватно.
Ато надоели все эти вопли про «viewstate is evil» и прочую дребедень. Дошли даже до того, что и codebehind теперь «evil». Люди начинают забывать в чем была крутизна WebForms как только они появились, и многие не понимают что сильные стороны WebForms абсолютно актуальны и сейчас. Вся критика на самом деле из-за незнания инструмента, с которым работаешь.
Адекватно и взвешенно, побольше бы таких постов.
Ато надоели все эти вопли про «viewstate is evil» и прочую дребедень. Дошли даже до того, что и codebehind теперь «evil». Люди начинают забывать в чем была крутизна WebForms как только они появились, и многие не понимают что сильные стороны WebForms абсолютно актуальны и сейчас. Вся критика на самом деле из-за незнания инструмента, с которым работаешь.
Адекватно и взвешенно, побольше бы таких постов.
В чем сила то? В дурной идее сымитировать поведение десктопного приложения? Прпи том что сегодня, наоборот, даже десктопные программы могут делаться на MVC. А все эти viewstate, и прости господи, визуальный редактор веб-страниц — кошмар разработчикаЮ, имхо.
Простая задача: сделать редактор сущностей, которые можно фильтровать по определенному критерию и выводить постранично.
Первый способ: MVC и хелперы.
Второй на WebFroms с использованием ListView, DataPager и DropDownList для фильтрации. Как думаете, где решение лучше получится и быстрее?
Первый способ: MVC и хелперы.
Второй на WebFroms с использованием ListView, DataPager и DropDownList для фильтрации. Как думаете, где решение лучше получится и быстрее?
Да одинаково, на самом деле.
Но вот сделать такую штуку для нескольких сущностей с максимальным реюзингом будет проще всего в ASP.NET MVC.
Но вот сделать такую штуку для нескольких сущностей с максимальным реюзингом будет проще всего в ASP.NET MVC.
Дык в реальности как правило, есть какие нибудь мелочи, или особенности, все равно код придется писать. К тому же эти .NET такой отвратительного качества код генерируют.
Если вы не заморачиваетесь с тестированием — то второй метод быстрее. Он еще и проверенный. Но если используете DDD, то MVC уже удобнее, так как все равно код писать.
MVC мне нужен для того, для чего он не нужен вам ))
вообще очень удобная платформа, нет ничего лишнего.
жду продолжения цикла )
вообще очень удобная платформа, нет ничего лишнего.
жду продолжения цикла )
Полностью согласен с пунктами «за» и «против». Именно эти три пункта «за» являются преимуществами ASP.NET MVC перед классическим ASP.NET. Остальные черты MVC фреймворка, как то паттерн MVC, полный контроль над HTML, отсутствие ViewState, PostBack'ов и событий, красивые URL адреса — не более, чем черты, но не преимущества.
В частности, полный контроль над HTML — на мой взгляд преувеличение. «Неполный» контроль в классическом ASP.NET объясняется использованием серверных web-контролов, которые рендерят сомнительный по качеству HTML. Не используйте их или используйте свои web-контролы, и будет «полный» контроль.
До тех пор, пока в ASP.NET MVC используются несложные хэлперы для генерации HTML, с чистотой кода все ОК. Но как только появятся control suites от DevExpress и прочих, контроль над кодом точно так же потеряется.
В частности, полный контроль над HTML — на мой взгляд преувеличение. «Неполный» контроль в классическом ASP.NET объясняется использованием серверных web-контролов, которые рендерят сомнительный по качеству HTML. Не используйте их или используйте свои web-контролы, и будет «полный» контроль.
До тех пор, пока в ASP.NET MVC используются несложные хэлперы для генерации HTML, с чистотой кода все ОК. Но как только появятся control suites от DevExpress и прочих, контроль над кодом точно так же потеряется.
К тому же красивые URL адреса от mvc и в winforms отлично работают
кстати, спасибо, напомнили, я про URL тоже хотел написать, но забыл
Обновил статью:
* вам не нужен MVC Framework, если вы хотите получить удобочитаемые URL. Механизм маршрутизации, который позволяет представлять удобочитаемые URL является частью ASP.NET, но не внутренней частью MVC Framework, поэтому использовать маршрутизацию и создавать удобочитаемые URL-ы вы можете и в классическом ASP.NET, MVC Framework для этого вам не нужен.
Обновил статью:
* вам не нужен MVC Framework, если вы хотите получить удобочитаемые URL. Механизм маршрутизации, который позволяет представлять удобочитаемые URL является частью ASP.NET, но не внутренней частью MVC Framework, поэтому использовать маршрутизацию и создавать удобочитаемые URL-ы вы можете и в классическом ASP.NET, MVC Framework для этого вам не нужен.
Проостите, в winforms?
> Не используйте их или используйте свои web-контролы, и будет «полный» контроль.
И вот тут две трети программеров начинают выть и стучать ногами по полу: «Не хочу, не буду!» — под миллиардом предлогов: «А это в чужом коде зашито», «А это долго», «А что плохого в форме на весь body?», «А тут просто не получится», «А это и так должно верстаться», «А тут надо много переписывать», «А тут логика не позволяет»…
И вот тут две трети программеров начинают выть и стучать ногами по полу: «Не хочу, не буду!» — под миллиардом предлогов: «А это в чужом коде зашито», «А это долго», «А что плохого в форме на весь body?», «А тут просто не получится», «А это и так должно верстаться», «А тут надо много переписывать», «А тут логика не позволяет»…
Честно говоря, не вижу разницы, встраивать яваскрипты в классическом аспнете или в mvc. И там и там это делается достаточно легко. Нет никаких проблем даже при использовании каких-то фреймворков, например jQuery.
я не могу знать какие вы делали проекты и как в них связывались javascript и web forms, но мой опыт говорит мне, что работа с автогенерируемыми идентификаторами пользовательских элементов управления через javascript — это трудозатраное дело. Втыкать всюду в коде скрита вставки с ClientId — это не айс, как не крути.
Можно использовать селекторы не только по id, а например по class. Ну и в крайнем случае, задавать ивенты элементам inline.
выкрутиться всегда можно, речь не об этом, в MVC это делать просто не нужно
Меня немного пугает, полный контроль над id. Если я например помещу на страницу селект со списком производителей, и хочу чтобы при выборе производителя у меня производилась фильтрация по нему (фактически перенаправление на другую страницу), то используя серверный селект и используя вставку с ClientID я уберегу себя от случайного размещения контрола с таким же id (например VendorList, ну мало ли приспичит вставить).
UFO just landed and posted this here
я в нашем проекте пошел другим путем. Выцеплял значение контролов из постбека путем добавления к их имени этих всяких id separator.
Решение, конечно, не айс, но вот пример:
А потом доставал значение:
Решение, конечно, не айс, но вот пример:
String prefix = elements.NamingContainer.UniqueID + ((PaymentFillControl)(this)).IdSeparator.ToString();
А потом доставал значение:
val = Utils.GetParamValue(Request, prefix + _fpc[i].ControlName);
UFO just landed and posted this here
Чудно…
Всё время пытался сказать эти за и против, но никак не доходили руки конкретизировать…
Всё время пытался сказать эти за и против, но никак не доходили руки конкретизировать…
Интересующим порекомендовал «погуглить» в рунете, в торрентах: Разработка веб-приложений с использованием ASP.NET MVC Framework Автор: Гайдар Магдануров. Это видео с зимних мастер-классов в московском офисе Microsoft. В частности, Гайдар высказался на тему этого топика: чем интересен ASP.NET MVC
гуглить не надо, наверняка, все эти ведео есть на techdays.ru
>Времена поменялись, меняется и классический ASP.NET, в нем есть множество инструментов по поддержке AJAX-функционала.
AJAX, реализованный стандартными средствами ASP.NET не юзабелен и его лучше вообще не трогать пока AJAX ASP.NET 4.0 не выйдет.
«за» и «против» написанные тут, личное мнение, основанное на личном опыте. Согласен только в одном, что MVC не лекарство от кривых рук. И переходить с чего-то на что-то тоже не выход. Тут больше надо смотреть на задачу, и исходя из задачи использовать ту или иную платформу.
Но, если ты хочешь увидеть зелёный цвет в W3C валидаторе, используй MVC.
AJAX, реализованный стандартными средствами ASP.NET не юзабелен и его лучше вообще не трогать пока AJAX ASP.NET 4.0 не выйдет.
«за» и «против» написанные тут, личное мнение, основанное на личном опыте. Согласен только в одном, что MVC не лекарство от кривых рук. И переходить с чего-то на что-то тоже не выход. Тут больше надо смотреть на задачу, и исходя из задачи использовать ту или иную платформу.
Но, если ты хочешь увидеть зелёный цвет в W3C валидаторе, используй MVC.
>Но, если ты хочешь увидеть зелёный цвет в W3C валидаторе, используй MVC.
Только до тех пор, пока весь код пишется вручную или генерируется проверенными хэлперами
Только до тех пор, пока весь код пишется вручную или генерируется проверенными хэлперами
Пользуюсь стандартными хэлперами или своими. Сторонние библиотеки мне не попадались. Буду рад ссылке, посмотреть что за оные.
Насколько я знаю про известных разработчиков UI, сейчас контролы под ASP.NET MVC есть только у Syncfusion — www.syncfusion.com/Products/aspnet-mvc. Я имею ввиду контролы, соответствующие идеологии ASP.NET MVC, т.е. генерирующие код через хэлперы, а не серверные web-контролы, адаптированные под MVC. У Telerik, например, есть именно такие.
>Но, если ты хочешь увидеть зелёный цвет в W3C валидаторе, используй MVC.
Только до тех пор, пока весь код пишется вручную или генерируется проверенными хэлперами
Только до тех пор, пока весь код пишется вручную или генерируется проверенными хэлперами
> Но, если ты хочешь увидеть зелёный цвет в W3C валидаторе, используй MVC.
В WebForm это не проблема, был у меня как-то простенький сайтец с зелеными валидаторами.
В WebForm это не проблема, был у меня как-то простенький сайтец с зелеными валидаторами.
Да и не только простенький можно сделать валидным, было бы желание.
Как-то занимался вопросом, захотелось в этом поупражняться — все получилось. А написать кривого кода можно и в MVC. WebForms — это ведь не только Menu и GridView.
Как-то занимался вопросом, захотелось в этом поупражняться — все получилось. А написать кривого кода можно и в MVC. WebForms — это ведь не только Menu и GridView.
Как то за всё время Menu ни разу не пришлось использовать…
Как я уже говорил надо рассматривать саму задачу. И использовать то или иное, или всё вместе (часто приходится писать сам сайт на MVC, а админку на WebForms).Скорость генерации разметки на MVC >> чем на WebForms.
У MVC хватает своих минусов: нет инструментария WebForms (трэйсинг например) или output кэш не такой гибкий (нет подстановки в кэш).
Как я уже говорил надо рассматривать саму задачу. И использовать то или иное, или всё вместе (часто приходится писать сам сайт на MVC, а админку на WebForms).Скорость генерации разметки на MVC >> чем на WebForms.
У MVC хватает своих минусов: нет инструментария WebForms (трэйсинг например) или output кэш не такой гибкий (нет подстановки в кэш).
>AJAX, реализованный стандартными средствами ASP.NET не юзабелен и его лучше вообще не трогать пока AJAX ASP.NET 4.0 не выйдет
Зато этот AJAX прикручивается к простенькой формочке за 2 минуты.
И почему он не юзабелен?
Зато этот AJAX прикручивается к простенькой формочке за 2 минуты.
И почему он не юзабелен?
Потому что простейшая задача, например проверки существования введённого имени. Ведёт к тому что на серверной стороне, помимо того что будет выполнен запрос к БД на проверку существования пользователя, будет по новому сгенерировна вся страница, потом страница отошлётся пользователю и JS на пользовательской стороне обновит только блок находящийся в UpdatePanel. И это только раде того что бы узнать«есть такой пользователь или нет?».
Да, зато это можно сделать быстро стандартными средствами ASP.NET AJAX, но я лучше напишу веб сервис, и используя, какой либо js фрэймворк сделаю ajax запрос к этому веб сервису.
Да, зато это можно сделать быстро стандартными средствами ASP.NET AJAX, но я лучше напишу веб сервис, и используя, какой либо js фрэймворк сделаю ajax запрос к этому веб сервису.
ASP.NET AJAX красиво работает с web-сервисами, еще лучше чем с update panel
Вы хотите тотальной оптимизации. Это плохой повод говорить, что asp.net ajax невозможно использовать.
Если правильно им пользоваться, то обработка ajax-запросов будет выполняться без задержек, а, как говориться, если нет разницы…
Если правильно им пользоваться, то обработка ajax-запросов будет выполняться без задержек, а, как говориться, если нет разницы…
Отличная подборка аргументов за и против.
От себя хотелось бы сказать следующее: в последнее время я очень сильно увлекся Ruby веб-стеком Ruby On Rails/Merb (очень жду Rails3), по сравнению с этой платформой (именно платформой, а не каркасом), ASP.NET MVC пока немного неуклюж и не элегантен. Но в связи с тем, что .NET — основная моя платформа, и у меня пока нет острой необходимости в работе с ASP.NET MVC, я буду смотреть в сторону стека IronRuby on Rails, где получу максимум интеграции и максимум элегантности и легкости решений
От себя хотелось бы сказать следующее: в последнее время я очень сильно увлекся Ruby веб-стеком Ruby On Rails/Merb (очень жду Rails3), по сравнению с этой платформой (именно платформой, а не каркасом), ASP.NET MVC пока немного неуклюж и не элегантен. Но в связи с тем, что .NET — основная моя платформа, и у меня пока нет острой необходимости в работе с ASP.NET MVC, я буду смотреть в сторону стека IronRuby on Rails, где получу максимум интеграции и максимум элегантности и легкости решений
«вам не нужен 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 его только используют для своих целей.
Очень уж субъективно. Сравнивается, как я понял ASP.NET WebForms и ASP.NET MVC? Ибо и то, и другое — ASP.NET. У каждой технологии своя концепция. И что значит переходить неоткуда? А если команда начинает использовать ASP.NET, до этого используя RoR, Django, CakePHP и так далее?
Для того, чтобы успешно использовать ASP.NET MVC, далеко не обязательно знать концепцию WebForms.
А ASP.NET — это просто «движок», «runtime», и WebForms с MVC его только используют для своих целей.
В точку. Старый Web Forms фреймворк знать совершенно не обязательно, поскольку это альтернатива, а никак не база. Базой же в обоих случаях выступает ASP.NET. В доказательство своих слов могу привести пример одного из наших программистов, который совершенно не знает Web Forms, что нисколько не мешает ему программировать на MVC.
MVC архитектурный шаблон красив на первый взгляд. И он действительно работает в простых задачах. Однако про попытке воспользоваться им при разработке более-менее сложных приложений быстро упираешься в проблему — код становится малоуправляемым и его действительно сложно эффективно раширять. Для решения данной проблемы в свое время были сделаны 2 независимых предложения: hMVC и PAC. Настоятельно рекоммендую посмотреть в их сторону. Есть неплохая статья про PAC например здесь: www.dossier-andreas.net/software_architecture/pac.html
UFO just landed and posted this here
Согласен с каждым пунктом из раздела «Почему вам НЕ нужен MVC Framework», во втором разделе очевидным является лишь пункт про юнит тесты.
И ещё меня волнует вопрос reusability. Если в «классическом» ASP.NET были контролы (controls), то как с этим обстоят дела в ASP.NET MVC? Или, если развернуть вопрос по-другому, есть ли перспективы и возможности для создания коммерческих библиотек (расширений, контроллеров или чего?) для ASP.NET MVC?
И ещё меня волнует вопрос reusability. Если в «классическом» ASP.NET были контролы (controls), то как с этим обстоят дела в ASP.NET MVC? Или, если развернуть вопрос по-другому, есть ли перспективы и возможности для создания коммерческих библиотек (расширений, контроллеров или чего?) для ASP.NET MVC?
мне известны проекты по созданию helper-методов для MVC-версии Grid, есть очень мощные проекты по созданию альтернативных view engine, в том числе например на базе ironruby (проект Spark). Правда, это некоммерческие проекты, но ничего не мешает развивать в эту сторону проекты в коммерческом плане.
есть оч. хорошая библиотека MvcContrib (codeplex) которая решает кучу проблем с гридами, их пейджингом и приносит много минут радости и счастья разработчику, а еще очень хорошие вещи находятся в ASP.NET MVC Futures. MVC как-бы хорош при использовании бэкенда в виде DataClasses или DataEntities, когда классический WebForms и его библиотека контролов предполагает работу с DataSet.
А как напрямую связаны MVC и «DataClasses или DataEntities»?
речь шла о ASP.NET MVC Framework, если внимательно следить за таймлайном развития фреймворка и блогами разработчиков сего чуда, то можно про себя и вслух отметить то, с какой любовью они продвигают их, применительно к DAL приложений на mvc framework.
О том и речь, что MVC Framework — это каркас приложения в веб-контексте, а с DAL этот каркас никак не связан напрямую. Можно сказать, что буква M — весьма условное понятие в ASP.NET MVC. В нем нет никаких механизмов, классов и фреймворков для Domain Modeling, чтобы получить те самые «Data Classes и Data Entities». Так что вопрос того, что вместе с MVC использовать на уровнях BLL и DAL — прерогатива разработчиков конкретного прикладного решения или проекта.
Отличные примеры «за» и «против». Согласен со всеми аргументами.
Я бы еще добавил, что MVC Framework и классический ASP.NET хороши для различного типа задач.
Например, блог или электронное представление газеты, на мой взгляд, удобнее делать с использованием MVC (мало форм ввода данных и много вывода информации в различных представлениях)
Но, например, большая на 3-4 страницы форма ввода данных на MVC — это мазохизм, хотя и реально реализуемо. Тут лучше использовать ASP.NET с валидаторами, ViewState и т.д.
Еще мне очень нравится тот темплейт, который устанавливается в студию вместе с MVC — для маленького проектика на 8 часов именно то, что нужно. Быстрый старт, так сказать.
Я бы еще добавил, что MVC Framework и классический ASP.NET хороши для различного типа задач.
Например, блог или электронное представление газеты, на мой взгляд, удобнее делать с использованием MVC (мало форм ввода данных и много вывода информации в различных представлениях)
Но, например, большая на 3-4 страницы форма ввода данных на MVC — это мазохизм, хотя и реально реализуемо. Тут лучше использовать ASP.NET с валидаторами, ViewState и т.д.
Еще мне очень нравится тот темплейт, который устанавливается в студию вместе с MVC — для маленького проектика на 8 часов именно то, что нужно. Быстрый старт, так сказать.
Не очень убедительно.
На мой взгляд главная особенность ASP.NET MVC — это правильная постановка мышления у новых разработчиков. И это важнее любых технологических достоинств.
вам не нужен 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 буду знать не только я, а ещё и вся команда.
Есть ли люди, которые после 'серьезной' работы со структурой приложения MVC, вернулись к предыдущей?
На мой взгляд обратной дороги нет! ))
Я считаю это утверждение (как и большинство остальных) говорит о малом опыте работы с MVC.
На мой взгляд обратной дороги нет! ))
Если вы думаете, что MVC Framework лучше ASP.NET, значит вы не полюбили ASP.NET и не поняли всей прелести его идеологии. В таком случае вам рано переходить на MVC Framework.
Я считаю это утверждение (как и большинство остальных) говорит о малом опыте работы с MVC.
Дает ли классический ASP.NET полное разделение разработки на server side и client side?
ASP.NET MVC дает. При работе с ним есть все возможности развести две команды по углам и дать им трудиться совершенно раздельно(согласуя форматы данных)
ASP.NET MVC дает. При работе с ним есть все возможности развести две команды по углам и дать им трудиться совершенно раздельно(согласуя форматы данных)
Судя по коментам, не далек тот день, когда начнутся холивары между разработчиками на ASP.NET Forms и ASP.NET MVC…
Лично я, согласен с автором по-всем пунктам. Еще один важный момент — это скорость разработки. MVC по-этому пункту проигрывает с большим отрывом, а это довольно важный пункт в современных реалиях.
Лично я, согласен с автором по-всем пунктам. Еще один важный момент — это скорость разработки. MVC по-этому пункту проигрывает с большим отрывом, а это довольно важный пункт в современных реалиях.
Поддерживаю замечание по скорости разработки. MVC требует больше времени на реализацию одной и той же (усредненной) задачи, хотя в перспективе, возможно, упростит внесение изменений в существующий продукт.
Да, об этом можно будет и кино снять: «Давным-давно разработчики asp.net были едины и вместе сдерживали нападения php-программистов, но потом произошел Великий Раскол и началась война...» :o)
MVC проигрывает в скорости разработки? Почему? На мой взгляд наоборот практически всё получается быстрее.
Единственное что будет медленнее, это очень навороченный грид, но тогда я в любом случае возьму Flexigrid, например.
Единственное что будет медленнее, это очень навороченный грид, но тогда я в любом случае возьму Flexigrid, например.
Та ну как же быстрее… Например: требуется сделать сайт, который поддерживает регистрацию пользователей, восстановление пароля, разделение прав, содержит пару больших форм с проверкой данных (полей этак по 25). Ну и табличные данные с различными фильтрами и сортировками. При должном опыте, на ASP.NET WinForms это час работы…
Ну не час на ASP.NET, даже если использовать Dynamic Data.
К тому же это такой идеальный сайт, прямо из примера на Dynamic Data, в жизни обычно есть куча особенностей.
Но даже если так, aspnet_User и прочий default membership довольно по дурацки выглядит в базе и потенциально неудобен.
Большая форма с некоторой ловкостью рук пишется за 10 мин (foreach… GetType().GetProperties()), Model Binder.
Табличные данные — это да, но я возьму готовую AJAX таблицу и всё ещё и быстрее будет.
При этом в итоге мы имеем сайт который получился не потому, что технология идеально подходит под задачу, а потому что технология простая и ненавязчивая.
Плюс у нас есть авторизация на уровне каждого действия, логика и разметка почти не повторяются, и страницы небольшие и быстро грузятся.
К тому же это такой идеальный сайт, прямо из примера на Dynamic Data, в жизни обычно есть куча особенностей.
Но даже если так, aspnet_User и прочий default membership довольно по дурацки выглядит в базе и потенциально неудобен.
Большая форма с некоторой ловкостью рук пишется за 10 мин (foreach… GetType().GetProperties()), Model Binder.
Табличные данные — это да, но я возьму готовую AJAX таблицу и всё ещё и быстрее будет.
При этом в итоге мы имеем сайт который получился не потому, что технология идеально подходит под задачу, а потому что технология простая и ненавязчивая.
Плюс у нас есть авторизация на уровне каждого действия, логика и разметка почти не повторяются, и страницы небольшие и быстро грузятся.
Час, минут 30 даже… А страницы и так не большие и быстро грузятся… Учите ASP.NET :)
Про готовый и отлаженный и испытанный в самых жёстких боевых условиях Membership — это отдельный разговор.
Про готовый и отлаженный и испытанный в самых жёстких боевых условиях Membership — это отдельный разговор.
Было бы забавно сделать видео — полчаса на сайт на ASP.NET.
Да, если совсем быстро и под задачу, я думаю, можно и полчаса.
Но задача должна быть идеальная.
Кстати, на мой взгляд, то что в ASP.NET можно учить (lifecycle, ashx, modules, services, state, health monitoring, cache) как раз выходит за рамки получасовой задачи. :)
Да, если совсем быстро и под задачу, я думаю, можно и полчаса.
Но задача должна быть идеальная.
Кстати, на мой взгляд, то что в ASP.NET можно учить (lifecycle, ashx, modules, services, state, health monitoring, cache) как раз выходит за рамки получасовой задачи. :)
Вопрос к автору — почему для вашего сайта Вы использовали движок KIGG, который и реализован с помощью ASP.NET MVC?
Для меня MVC — решение многих проблемы, которые были на php
Sign up to leave a comment.
ASP.NET MVC Framework – ставим точки