Sep 29, 2010

Почему не asp.net и про собеседования

После довольно продолжительной работы с asp.net mvc пришлось перечитать книгу по asp.net. Казалось бы многие утверждают, что начинать проще с веб форм, а только потом уже переходить на mvc. Но давайте посмотрим на 2 картинки из книги для подготовки к экзамену по asp.net:

simple request

Все просто и понятно. Браузер запросил страничку, сервер её построил и вернул. Теперь посмотрим на другую:

 жизненный цикл страницы

Несколько длинный путь по сравнению с первой картинкой…

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

Мало того, если еще гора правил по использованию этих событий (которые почему то все невероятно любят спрашивать на разного рода тестах и собеседованиях) типа: тему и мастер пейдж можно задать только на этапе PageInit, но на PageInit еще не доступен ViewState, последнее событие, на котором можно изменить ViewState это Prerender – на последующих событиях эти изменения игнорируются и т.д.

confused-man Событийная модель asp.net невероятно сложна в понимании. Особенно весело становится, если рассмотреть порядок вызова событий для страницы, которая содержит MasterPage + ContentPage + UserControl. Это список из 17 ОСНОВНЫХ событий,  без учета всех PreInit, PreRender и прочих.
И это все чтобы создать одну html страницу… 17 событий, хотя случилось всего одно событие – на сервер пришел запрос.

Так же в ASP.NET есть поддержка тем (кстати ни одного приложения с использованием этой фичи не встречал), но опять же, есть ряд правил их применения:

порядок применения тем

Подобные примеры можно приводить до бесконечности. Под конец беглого просмотра книги складывается впечатление что asp.net это огромный набор различных “gotcha” и “WTF!?”.

Сертификационные экзамены сплошь набиты вопросами именно на эти темы. Порядок вызовов, приоритеты применения, файлы настроек, и так до бесконечности.

Видимо из-за этого подобные же вопросы очень любят задавать на разного рода собеседованиях. Неужели именно эти знания делают человека хорошим разработчиком? Что проверят экзаменующие получив ответы?

В mvc нет событийной модели, но мне совершенно это не мешало, а скорее наоборот сделало гораздо более понятней происходящее в веб. Стало понятно почему приложения должны следовать правилу post-redirect-get, и что означает окошко браузера типа:

2010-09-29_2340

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

Т.е. у меня ушло около года чтобы изучить все эти совершенно не очевидные правила asp.net, но не понять основных и самых элементарных принципов работы веб приложений и http протокола в целом.

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

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

8 comments:

  1. последнее предложение надо просто отлить в золоте.

    ReplyDelete
  2. Когда начал читать, еще не знал автора.
    Спасибо. Интересно.

    ReplyDelete
  3. Я тоже когда начинал читать (было мне года 3), ещё не знал автора =)

    Вывод действительно правильный, акцента на нём только мало.

    ReplyDelete
  4. Потому что вывод родился во время написания поста. Вообще я собирался просто пожаловаться какое же asp.net ... :)

    ReplyDelete
  5. Я тоже когда начинал читать (было мне года 3), ещё не знал автора =)
    ))))
    Просмотрел коммент.

    ReplyDelete
  6. Андрей, у вас на второй картинке показана очередность этапов. Сначала State 5: Validation, а затем State 6: PostBack Event Handling.

    На MSDN ресурсе (http://msdn.microsoft.com/ru-ru/library/ms178472.aspx) почти в самом начале "General Page Life-Cycle Stages" следующее:
    Stage "Postback event handling"
    If the request is a postback, control event handlers are called. After that, the Validate method of all validator controls is called, which sets the IsValid property of individual validator controls and of the page.

    Так какой же все-таки порядок правильный? Сначало Validation, а затем PostBack Event Handling или наоборот?
    Прошу простить, если вопрос поставлен некорректно. :) Я так же работая с ASP, еще не понимаю событийную модель, но очень хочу изучить.

    Заранее благодарю!

    ReplyDelete
  7. Картинка взята из книги подготовки к сертификации MCTS по ASP.NET. Не думаю что настолько важно помнить их порядок. Для запоминания существует довольно удобная мнемоника (обычно нужна только на собеседованиях)
    S - start
    I - init
    L - load
    V - validation
    E - event handling
    R - render

    ReplyDelete
  8. Испытвая сходие чувства, в свое время написал следующий пост)

    http://www.beletsky.net/2011/03/aspnet-developers-disease.html

    ReplyDelete