Комментарии 83
может лучше перенесете в группу .NET?
Поставь ссылку на http://www.asp.net/mvc/ с описанием технологии
Не прошло и полгода, как в ASP.Net появился MVC ]:-) Но честно говоря, из-за не утиной типизации в C# кода очень много и выглядит он не так красиво. Это касается и роутеров (никакого файла конфига, роутеры надо настраивать в классе) и тестирования (никакого понятного синтаксиса RSpec типа «obj.method(:build).should raise_error»).
никакого понятного синтаксиса RSpec типа «obj.method(:build).should raise_error»
Ээм?! У меня походу разрыв.. Я не понимаю..с ноября до апреля вроде разрывов не было:)
Ээм?! У меня походу разрыв.. Я не понимаю..с ноября до апреля вроде разрывов не было:)
Мне кажется, что вы погярячились. Это уже .NET 3.5 и в нём с типизацией как раз очень гибко. И конфиги для роутингов можно делать:
http://weblogs.asp.net/fredriknormen/archive/2008/03/11/asp-net-mvc-framework-2-define-routes-in-web-config.aspx
http://weblogs.asp.net/fredriknormen/archive/2008/03/11/asp-net-mvc-framework-2-define-routes-in-web-config.aspx
Конфиги в XML?! O_o Честно говоря, настройки, которые правят руками не эффективно сохранять в XML. YAML, например, подходит лучше. Конечно не что не мешает написать свой парсер для YAML, который вызывает методы .Net, но в Rails или Merb всё идёт из коробки.
"не эффективно" - мне страшно:) А почему "не эффективно"?
Потому что надо закрыть теги, потому что «<имя>значение » читается хуже, чем «имя: значение». Список создавать не удобно. В общем, YAML лучше подходит для данных типа ключ => значение. Например, сравните примеры http://www.kuro5hin.org/story/2004/10/29…
Я не об этом. Удобство, само собой, понятно:) Эффективность - это страшное слово. Им все можно описать. Что имелось ввиду? Вдруг попадется чел, который реально эффективней пишет на XML?!
Ну, например, кол-во лишних символов в XML (закрывающиеся теги) и кол-во исключительных ситуаций (незакрытый тег) вполне научно обосновывают эффективность при ручном вводе ;)
А что в них неэффективного? Их на столько больше, что парсер будет тормозить? Это же какой файл настроек надо иметь?:)
Предлагаю "Эффктивность" как понятие в контексте практических задач рассматривать.
Например, эффективность распознавания монгольцев работниками российской таможни в аэропорте Уланбатора. (Это лишь пример!)
Предлагаю "Эффктивность" как понятие в контексте практических задач рассматривать.
Например, эффективность распознавания монгольцев работниками российской таможни в аэропорте Уланбатора. (Это лишь пример!)
Я говорю, про эффективность набора (я же специально сказал, что имею в виду только случаи конфигов, которых правят руками). Чем больше лишних символов — тем больше ввод, теряешь мысли. Чем больше исключительных ситуация — тем больше вероятность ошибки.
Если я не ошибаюсь, то и для YAML уже что-то есть. Надо почаще проверять dotnetkicks.com ;)
А с роутами суть в том, что можно хранить их как угодно и где угодно, никто не мешает строить их динамически в нужном месте, будучи вытащенными "откуда-угодно".
А с роутами суть в том, что можно хранить их как угодно и где угодно, никто не мешает строить их динамически в нужном месте, будучи вытащенными "откуда-угодно".
Тут-то придётся сразу настроить, а в «конкурирующих решениях» ;) надо доводить ручками, если вы отличаетесь от 90 % типовых сайтов (динамически генерировать конечно же тоже можно).
А ручки они на то и даны, чтобы доводить ими:) "Универсальные" решения всех задач web-программирования мне не знакомы. Поделитесь, если знаете.
Я же говорю, что «из коробки» идёт не универсальное, а типовое решение, которые не в 100 %, а лишь в большинстве случаев подходит. Но это резко сокращает время. Например, логично, что роутеры лежат в конфиги (в 90 % случае это так), контроллеры лежат в одной папке, а представления в другой и т. д. Т. е. такая типовая заготовка.
Нее, MS понимает, что делает продукт для разработчиков на максимальную аудиторию.
И часто даже нелогичные решения имеют очень логичное объяснение.
MS понимают, что создают свой framework для миллионов разработчиков, которые будут делать продукты для сотен миллионов конечных пользователей.
Какие уж там 90%, когда можно 100%, а остальное "допишут на месте".
И часто даже нелогичные решения имеют очень логичное объяснение.
MS понимают, что создают свой framework для миллионов разработчиков, которые будут делать продукты для сотен миллионов конечных пользователей.
Какие уж там 90%, когда можно 100%, а остальное "допишут на месте".
В идеале framework должны писать и сторонние разработчики. Во всех «конкурирующих решениях» разработчики языка и framework’а не связаны и существует много framework’ов для разных задач. Например, если используется активно кеширование, то от классических роутеров вообще можно отойти — банально возвращая кеш из памяти и т. д.
Ну, так скажем, framework от MS вполне может являться базой для какого-то более узкоспециалированного, прикладного фреймворка.
Мне тоже понравилась эта идея в Zend Framework. Framework для framework’ов. Но честно говоря, всё равно это не будут framework’и, а лишь набор конфигов. Например, merb был начат из-за того, что ему не нравился принцип роутинга в rails. Тут так не получится — нет свободы. Например, может нужна более тестная интеграция с IIS. Например, у Ruby не нужно было специальных технологий типа ASP.Net для работы с вебом. Запускался обычный ruby-процесс, который подсоединялся к веб-серверу.
Здесь не соглашусь. MS сейчас делают отличную работу в плане развязывания компонентов. Допустим, если при работе с WebForms мы могли использоваться только "все сразу", то здесь можно любую часть заменить сторонней или собственной реализацией, как я уже говорил.
Насчет интеграции с IIS - можно настраивать все, вся, как угодно, где угодно, чтобы получить ровным счетом то, что нужно. Особенно это касается IIS7.
У Ruby не нужно было специальных технологий??? Это как? Ruby - это язык. Есть его реализация в .NET - IronRuby - вот вам специальная технология ASP.NET. Или RoR - вот вам специальная технология Rails.
Насчет интеграции с IIS - можно настраивать все, вся, как угодно, где угодно, чтобы получить ровным счетом то, что нужно. Особенно это касается IIS7.
У Ruby не нужно было специальных технологий??? Это как? Ruby - это язык. Есть его реализация в .NET - IronRuby - вот вам специальная технология ASP.NET. Или RoR - вот вам специальная технология Rails.
(кстати, RoR == Rails)
В том-то и дело, что Rails — это просто набор скриптов и библиотек. Merb (главный конкурент Rails) вообще весит 300 КБ и занимается чисто роутингом. Так что это никакая не технология. Я, например, писал в чистую веб-движок без всяких технологий — получал запросы от веб-сервера и выдавал ответ по FastCGI. Гибкость и прозрачность в итоге и как следствие огромный выбор framework’ов на все случаи жизни. С PHP так же — там нет специальной технологии, просто язык, framework’ов в итоге тоже много.
В том-то и дело, что Rails — это просто набор скриптов и библиотек. Merb (главный конкурент Rails) вообще весит 300 КБ и занимается чисто роутингом. Так что это никакая не технология. Я, например, писал в чистую веб-движок без всяких технологий — получал запросы от веб-сервера и выдавал ответ по FastCGI. Гибкость и прозрачность в итоге и как следствие огромный выбор framework’ов на все случаи жизни. С PHP так же — там нет специальной технологии, просто язык, framework’ов в итоге тоже много.
Подход MS отчасти плох тем, что они web server встроили в framework. Сама asp.net по сути и является web сервером (мнение основано на изучении сурсов mono - код xsp2 минимален, почти все делегируется в библиотеки asp.net). Поэтому и создается впечатление, что для работы с web'ом нужна технология asp.net. Но в её защиту следует заметить, что asp достаточно модульная вещь, и если нужно что-то особенное, то это легко можно сделать, оставаясь на низком уровне - используя http-handlers и http-modules. Именно так я реализовал templating через xslt.
Зачем бежать впереди паровоза:) Соглашусь, что часто возникает задача сохранения настроек. Но не могу согласиться с тем, что это самое трудное в проекте - хранить настройки. Я бы выбрал более консервативный XML, только лишь из-за присутствия класса XMLSerializer в .Net и отсутствия YAMLSerializer. На мой взгяд, я бы быстрее написал прокси-класс ко всем XML настройкам, чем разобрался с парсингом YAML.
Ну Вы же понимаете, что Вы используете менее удобный XML только потому, что в MS ещё верят а абсолют XML ;)
А почему верят? Потому, что нет достойной и универсальной замены. У XML всегда были трудности. Нельзя отрицать его недостатков, но зачем отказываться от преимуществ?!
Я имею в виду, что формат должен выбираться исходя из задачи. Передача объектов — JSON, конфиг — YAML, текст с вёрсткой — XML. Во время развития Java была популярна идея, что формат должен быть один и абсолютным форматом стал XML. .Net создавался как конкурент Java и унаследовал эту идею.
.NET и MVC Framework в частности, не налагает нииииикаких ограничений на формат хранения данных и формат выдачи. Вот вам нравится YAML, а мне вот нравится VasilioRuzanniML - почему бы им не встроить его в .NET?
P.S. Это утрированный пример, но суть должна быть понятна)
P.S. Это утрированный пример, но суть должна быть понятна)
Как-то странно получается. Я сам использую JSON. Также использую XML. Я тоже не являюсь апологетом XML, как и Вы. Но то ли какой-то подвох, то ли ещё что-то.
Тем не менее, мне кажется беседа сбилась на обсуждение "YAML лучше XML для хранения нстроек". Возможно, это тема для отдельного поста. Я думаю, это слишком сильное суждение. Что лучше, каждый должен выбирать в конкретном случае разработки.
Тем не менее, мне кажется беседа сбилась на обсуждение "YAML лучше XML для хранения нстроек". Возможно, это тема для отдельного поста. Я думаю, это слишком сильное суждение. Что лучше, каждый должен выбирать в конкретном случае разработки.
Причем тут абсолют XML для MS? XML - это W3C-стандарт.
Абсолют потому что они используют его везде. См. мой ответ выше.
Ну они то да, но это ведь не их формат. Хорошо, что они используют его, а не какой-нибудь специфичный (не являющийся XML, например) формат MSFileFormat.
С одной стороны и неплохо. Мне не нужно держать в голове несколько форматов. Все в одном виде описывается. Это мне кажется ка краз правильнее, чем использовать 10 разных способов описания вещей каких-то. Да и не составляет трудности читать XML файлы. Дело привычки.
Абсолютно согласен! Каждый проект в той или иной мере уникален, по крайней мере у нас, но я думаю и у большинства остальных тоже.
У вас каждый раз нужно роутеры хранить в разном месте :) O_o
Ну вовсе не обязательно, что в каждом.
Но допустим, для проектов по сайтам, роуты, жестко прописанные в структуре сайта берутся из одного места, а роуты для псевдо-статических страниц из другого и добавляются в таблицу роутов в другом месте.
Для одного проекта SOA - маршруты-конечные точки некоторых сервисов вообще получаются от "сервиса раздачи маршрутов".
Т.е. задача может быть сколь угодно специфично и при создании целого (относительно) низкоуровневого, с точки зрения веб-разработки, фреймворка - нельзя "прошить" в него какой-то один, "единственно верный" вариант.
Но допустим, для проектов по сайтам, роуты, жестко прописанные в структуре сайта берутся из одного места, а роуты для псевдо-статических страниц из другого и добавляются в таблицу роутов в другом месте.
Для одного проекта SOA - маршруты-конечные точки некоторых сервисов вообще получаются от "сервиса раздачи маршрутов".
Т.е. задача может быть сколь угодно специфично и при создании целого (относительно) низкоуровневого, с точки зрения веб-разработки, фреймворка - нельзя "прошить" в него какой-то один, "единственно верный" вариант.
Так в других framework’ах он не прошит :). Вы можете так же изменить и подогнать под свой очень сложный случай. Вопрос в том, что если вам повезло и вы попали под типовой случай, то всё уже настроено, а если нет, то точно так же можете настроить руками.
Ну нам ничто не мешало потратить чуток времени и сделать несколько нужных нам (по мере возникновения задач) реализаций один раз и использовать их в большинстве типовых проектов.
Т.е. считайте, что каждый сам определяет себе "типовой случай".
Т.е. считайте, что каждый сам определяет себе "типовой случай".
С советами плохо — можно сказу сказать — открой папку такую-то. Вообще один готовый скрипт написать, который сам всё поймёт :). В Rails — это активно используется. Т. е. у нас есть соглашения по именованию и ORM-класс User автоматически привязывается к таблице users. И в итоге пишут т. н. generator’ы, которые пишут рутинные действия, например форму админки по структуре БД. Если задача не типовая — пиши руками, если типовая — работа идёт гораздо быстрее.
Т.е. если я хочу создать класс User не привязанный к БД, я должен лишь указать это в соглашении?
Вообще не каждому может понравится, что кто-то думает за него, предлагая "решение по-умолчанию" и, тем самым, оказывая медвежью услугу. Якобы универсальное решение может оказаться ошибочным с течением времни и проект станет сложным. Этим кстати много грешил сам ASP.NET с WebForfm'сами.
Вообще не каждому может понравится, что кто-то думает за него, предлагая "решение по-умолчанию" и, тем самым, оказывая медвежью услугу. Якобы универсальное решение может оказаться ошибочным с течением времни и проект станет сложным. Этим кстати много грешил сам ASP.NET с WebForfm'сами.
YAML парсить конечрно можно: http://yaml-net-parser.sourceforge.net/
Но вот хранение такого рода конфигов в YAML'е - сомнительное удовольствие.
В одном из моих проектов на Zend Framework (где тоже MVC) роутинги хранились в ini-файле
routes.press_item.type = "Zend_Controller_Router_Route_Regex"
routes.press_item.route = "^((ru|en)/)?pr/(events|press)/([0-9a-zA-Z_\-\.,]+)/?$"
routes.press_item.defaults.controller = "press"
routes.press_item.defaults.action = "read"
routes.press_item.defaults.alias = ""
routes.press_item.map.2 = "lang"
routes.press_item.map.4 = "alias"
Тоже не ахти вышло, но легко поддерживаемо :-)
Но вот хранение такого рода конфигов в YAML'е - сомнительное удовольствие.
В одном из моих проектов на Zend Framework (где тоже MVC) роутинги хранились в ini-файле
routes.press_item.type = "Zend_Controller_Router_Route_Regex"
routes.press_item.route = "^((ru|en)/)?pr/(events|press)/([0-9a-zA-Z_\-\.,]+)/?$"
routes.press_item.defaults.controller = "press"
routes.press_item.defaults.action = "read"
routes.press_item.defaults.alias = ""
routes.press_item.map.2 = "lang"
routes.press_item.map.4 = "alias"
Тоже не ахти вышло, но легко поддерживаемо :-)
Ну ASP.Net как я понимаю будет парсить YAML эпизодически, так что ничего страшного. По поводу синтаксиса могу привести пример как пользовался я, когда ещё писал на PHP для того же ZF:
expo:
url: /expo/:expo/
controller: expo
stand:
url: /expo/:expo/:stand/
controller: stand
reqs:
stand: \d+
expo:
url: /expo/:expo/
controller: expo
stand:
url: /expo/:expo/:stand/
controller: stand
reqs:
stand: \d+
Ну YAML я имел в виду, потому что набивать роутеры прямо в C# — это маленький ад. В «конкурирующих решениях» роутеры это тоже код, но там из-за гибкости синтаксиса он не отличается от конфига. Пример:
Merb::Router.prepare do |r|
r.match('/').to(:controller => 'index')
r.match('/user/:id/').to(:controller => 'user')
r.match(/^\/about\/(.+)/).to(:controller => 'wiki', :name => '[1]')
end
В .Net 3.5 появилась «утиная» типизация?
Если имеется в виду это, то такого в нет этого нет. Но в 3.5 с типизацией лучше, чем в ранних версиях:)
Нет. Утиной нет, но анонимные классы уже есть :-). Думаю, в .NET 4 будет и утиная, ибо совсем недавно уже хотелсоь её в практической дяетельности
Родной нет.
http://www.deftflux.net/blog/page/Duck-T…
И вот еще Фил Хаак, один из создателей ASP.NET MVC пишет по теме (все англ.):
http://haacked.com/archive/2007/08/19/wh…
http://haacked.com/archive/2007/09/09/ih…
http://www.deftflux.net/blog/page/Duck-T…
И вот еще Фил Хаак, один из создателей ASP.NET MVC пишет по теме (все англ.):
http://haacked.com/archive/2007/08/19/wh…
http://haacked.com/archive/2007/09/09/ih…
Написали бы обзор что ли.
Те кто пишут на ASP.NET MVC сами узнают о новой версии, а те кто не пишут - им это ни к чему...
Те кто пишут на ASP.NET MVC сами узнают о новой версии, а те кто не пишут - им это ни к чему...
Ну почему же. Я вот только отсюда и узнал только что :)
А в работе мы использовали все версии ASP.NET MVC, а до этого еще и Castle Project MonoRail MVC и свою собственную реализацию.
А в работе мы использовали все версии ASP.NET MVC, а до этого еще и Castle Project MonoRail MVC и свою собственную реализацию.
Вот про MonoRail подробнее. Походу микросовты активно используют его для своей реализации MVC. Если верить их подкастам:)
Большие различия?
Большие различия?
У Microsoft сейчас получается получше (понавороченнее, в хорошем смысле. Т.е. без жертв простотой) и удобнее, да и ASP.NET MVC как MVC для .NET всяко будет "мейнстримнее", поэтому "вкладывать" в него есть смысл.
MonoRail на удивление хорошая вещь, более целостный на данный момент, но слишком медленно развивается.
Однако, при этом содержит массу идей и просто очень хорошо продуман. Например, имена namespace'ов, классов и методов - Microsoft многие вещи под чистую сдирает в этом плане, так как лучше и правда что сложно придумать :)
MonoRail на удивление хорошая вещь, более целостный на данный момент, но слишком медленно развивается.
Однако, при этом содержит массу идей и просто очень хорошо продуман. Например, имена namespace'ов, классов и методов - Microsoft многие вещи под чистую сдирает в этом плане, так как лучше и правда что сложно придумать :)
Я не проповедую ASP.NET MVC. Он пока не готов. А по поводу обзора подумаю. Вот только много писать придётся. Может целую серию забабахать?
Круто если сделаете сравнительную характеристику.
С MVC против Без MVC
А то ведь постоянно всякие обзоры идут, а не понятно - что дает фреймворк/система... Чем она выигрывает у простого подхода и т.п.
С MVC против Без MVC
А то ведь постоянно всякие обзоры идут, а не понятно - что дает фреймворк/система... Чем она выигрывает у простого подхода и т.п.
А никто вроде не позиционирует MVC, как замену тому, что уже есть. Но сравнить можно.
Вообще, много уже написано на эту тему. Я, например, очевидным вижу преимущество автоматического тестирования, которое в "классическом" ASP.NET затруднено.
Вообще, много уже написано на эту тему. Я, например, очевидным вижу преимущество автоматического тестирования, которое в "классическом" ASP.NET затруднено.
Майкрософтовцы сами говорят, что ASP.NET MVC ни в коем случае не отменяют концепции ВебФорм, и они будут поддерживать и развивать последние (кстати, подсистема маршрутов в MVC, не является частью MVC и может использоваться с WebForms).
Однако, сравнить, конечно можно. Но это просто разница в подходах.
Для нас MVC (мы делали даже свою реализацию, более сложную, но менее гибкую) - изначально была дорогой к качественному юнит-тестированию, чистому контролируемому коду, отсутствию необходимости во всякого рода post-back'ах и отсутствию других, использующих протокол http "не по назначению" штуках :)
Однако, сравнить, конечно можно. Но это просто разница в подходах.
Для нас MVC (мы делали даже свою реализацию, более сложную, но менее гибкую) - изначально была дорогой к качественному юнит-тестированию, чистому контролируемому коду, отсутствию необходимости во всякого рода post-back'ах и отсутствию других, использующих протокол http "не по назначению" штуках :)
НЛО прилетело и опубликовало эту надпись здесь
Кстати, вполне можно переводить те же туториалы от Скотта Гутри, Фила Хаака и Роба Конери. Будет более, чем полное описание.
Предлагаю, коллективом заняться.
По моему это лишнее. Вообще все переводы один в один - это лишняя работа, к тому же не благодарная. Впрочем, если кто-то чувствует силы, то может пойти по адресу http://ruspiegel.net/. Там энтузиаст с gotdotnet.ru выкладывает переводы по .net в том числе и ScottGu
О, MVC! Для меня больная тема, уже давно слежу за развитием этого Framework'а. Ибо, получив по первым сборкам какое-никакое представление, решил изобрести велосипед и сделать свою редакцию. Она, кстати, работает, и неплохо работает :)
В частности, я использую существенно измененный механизм для роутинга (в частности, у меня он позволяет учитывать в параметрах и субдомен, плюс есть провайдер для загрузки из БД) и немного переделанный и универсализированный собственно MVC.
Больше всего мне понравился inline-рендеринг компонентов, что, имхо, поудобнее, чем регистрация контрола и внедрение его где-то на странице. Обидно только, что partial-rendering (точнее, легкий способ его реализации), по-видимому, нас покинул. То, что добавили генерацию JSON (наконец-то!) несомненно, интересно, вопрос только в том, как именно. Сейчас скачаю и посмотрю...
В частности, я использую существенно измененный механизм для роутинга (в частности, у меня он позволяет учитывать в параметрах и субдомен, плюс есть провайдер для загрузки из БД) и немного переделанный и универсализированный собственно MVC.
Больше всего мне понравился inline-рендеринг компонентов, что, имхо, поудобнее, чем регистрация контрола и внедрение его где-то на странице. Обидно только, что partial-rendering (точнее, легкий способ его реализации), по-видимому, нас покинул. То, что добавили генерацию JSON (наконец-то!) несомненно, интересно, вопрос только в том, как именно. Сейчас скачаю и посмотрю...
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ASP.NET MVC 3 Preview