Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Maxim Golov, Вы писали:

MG>>Я не очень осознал набор утверждений "viewstate — это зло" и "Viewstate масштабируется гораздо лучше". Это не подколка, это вопрос — как их интерпертировать вместе?
S>Сессия — самое большое зло.
S>Viewstate — зло поменьше.
S>Stateless page — это самый правильный способ работы. Не всегда этот идеал достижим.
Просветит меня, в каких случаях >Stateless page — недостижимо?
на ум приходит только хранение секурной информации типа id разных не в QueryString а в хитрозашифрованном вьюстейте..
Есть еще какие то варианты?
Заранее спасибо!

J>Просветит меня, в каких случаях >Stateless page — недостижимо?
J>на ум приходит только хранение секурной информации типа id разных не в QueryString а в хитрозашифрованном вьюстейте..
J>Есть еще какие то варианты?
J>Заранее спасибо!

например сложный Wizard с большим количеством страниц. с каждым переходом информация накапливается, в конечной точке нужна информация по всем страничкам Визарда

Здравствуйте, mogadanez, Вы писали:

J>>Просветит меня, в каких случаях >Stateless page — недостижимо?
J>>на ум приходит только хранение секурной информации типа id разных не в QueryString а в хитрозашифрованном вьюстейте..
J>>Есть еще какие то варианты?
J>>Заранее спасибо!

M>например сложный Wizard с большим количеством страниц. с каждым переходом информация накапливается, в конечной точке нужна информация по всем страничкам Визарда
Можно сказать так:
State необходим когда бизнес транзакция состоит из нескольких запросов

Здравствуйте, Jericho113, Вы писали:
J>Просветит меня, в каких случаях >Stateless page — недостижимо?
Ну, например для интерактивных страничек.
J>на ум приходит только хранение секурной информации типа id разных не в QueryString а в хитрозашифрованном вьюстейте..
На всякий случай напомню, что размер querystring сильно ограничен. Поэтому если состояние странички больше полуторых килобайт, сохранить его в URL не удастся.

Синклер, спасибо за ответ, некоторое новое понимание определенно появилось.

Не пытаясь найти решение на все случаи жизни, а конкретно в нашем случае (бизнес-приложение, часть операций требует работы с большими объектами — до сотни параметров): в процессе таких операций хочется дать возможность сохраниться в середине процесса; в голову приходит либо айакс (сохранили драфт), либо визард или аналогичный способ заставить юзера нажать на кнопку для перехода к следующей стадии. Сохраняться при этом хочется не на страницу и не в сессию (которая может и умереть), а явно в базу. Ключ объекта можно таскать во вьюстейте, в скрытом контроле или в строке запроса (но закладку на него ставить будут разве что тестеры). Осталось придумать, как хранить в базе промежуточные версии объектов без слишком больших накладных расходов.

Что-то мелкое и не заслуживающее сохранения между логинами, видимо, имеет право жить во вьюстейте.

Здравствуйте, Maxim Golov, Вы писали:

MG>Синклер, спасибо за ответ, некоторое новое понимание определенно появилось.

MG>Не пытаясь найти решение на все случаи жизни, а конкретно в нашем случае (бизнес-приложение, часть операций требует работы с большими объектами — до сотни параметров): в процессе таких операций хочется дать возможность сохраниться в середине процесса; в голову приходит либо айакс (сохранили драфт), либо визард или аналогичный способ заставить юзера нажать на кнопку для перехода к следующей стадии. Сохраняться при этом хочется не на страницу и не в сессию (которая может и умереть), а явно в базу. Ключ объекта можно таскать во вьюстейте, в скрытом контроле или в строке запроса (но закладку на него ставить будут разве что тестеры). Осталось придумать, как хранить в базе промежуточные версии объектов без слишком больших накладных расходов.

MG>Что-то мелкое и не заслуживающее сохранения между логинами, видимо, имеет право жить во вьюстейте.

немного отвлеченно — драфты это вполне себе отдельная сущность и подлежит сохранению в базе как и любой нормальный объект

Здравствуйте, Sinclair, Вы писали:

S>Сессия — самое большое зло.

Я вот потихоньку пытаюсь решить такую задачу:

есть главная форма ReportSelector:
* там набор фильтров (дропдауны всякие, текст боксы и т.д.).
* линки к самим репортам, открываются в новой странице, параметры репортов передаются в QueryString (т.е. GET запрос).
* На страницах самих репортов есть миниатюрный вариант формы ReportSelector. Юзер может их поменять и нажать Submit (понятное дело POST, но при этом в QueryString остаются параметры GET из предыдущего пункта). Пока что это влияет только на текущий репорт.

Заказчик хочет, что бы значения ReportSelector запоминались. В текущей версии ему было отказано, но в следующей версии он это будет очень сильно хотеть. Единственный вариант, который я вижу — хранить параметры ReportSelector в сессии, и в ответ на GET запрос грузить параметры из сессии, а в ответ на POST запрос (если юзер нажал на кнопку ReportSelectorSubmit) обновлять значения параметров в сессии.

Юзабилити, конечно, будет кошмарным, но другого варианта я пока что не вижу.

Здравствуйте, B0rG, Вы писали:
BG>Я вот потихоньку пытаюсь решить такую задачу:

BG>есть главная форма ReportSelector:
BG>* там набор фильтров (дропдауны всякие, текст боксы и т.д.).
это понятно
BG>* линки к самим репортам, открываются в новой странице, параметры репортов передаются в QueryString (т.е. GET запрос).
это не вполне понятно: делается submit формы с method=get, или линки собираются вручную джаваскриптом? Впрочем, это не очень важно..
BG>* На страницах самих репортов есть миниатюрный вариант формы ReportSelector. Юзер может их поменять и нажать Submit (понятное дело POST, но при этом в QueryString остаются параметры GET из предыдущего пункта). Пока что это влияет только на текущий репорт.
Это непонятно. Почему POST? Почему не сделать GET?

BG>Юзабилити, конечно, будет кошмарным, но другого варианта я пока что не вижу.
Почему не сделать самый простой вариант: делать action="" в мини-форме? Если в ней нужны не все параметры из "большого" ReportSelector, то недостающие нужно просто отдать в виде input type=hidden.

Тут сессия вообще ни в каком месте не нужна.

Здравствуйте, Sinclair, Вы писали:

S>это не вполне понятно: делается submit формы с method=get, или линки собираются вручную джаваскриптом? Впрочем, это не очень важно..

BG>>* На страницах самих репортов есть миниатюрный вариант формы ReportSelector. Юзер может их поменять и нажать Submit (понятное дело POST, но при этом в QueryString остаются параметры GET из предыдущего пункта). Пока что это влияет только на текущий репорт.
S>Это непонятно. Почему POST? Почему не сделать GET?

Сделано по религии asp.net: методы вызываются по "эвентам" OnButtonClick.
т.е. в ответ на Get мы преселектим инпуты
В _OnButtonClick мы меняем значения контролей
В true == Page.IsPostBack мы собственно показываем данные

т.е. изменение состояния контролей регистрируется только в _OnButtonClick

BG>>Юзабилити, конечно, будет кошмарным, но другого варианта я пока что не вижу.
S>Почему не сделать самый простой вариант: делать action="" в мини-форме? Если в ней нужны не все параметры из "большого" ReportSelector, то недостающие нужно просто отдать в виде input type=hidden.

интересная идея надо бы посмотреть. У меня получалось так:
открываем новую страницу через GET, в урл параметры
давим Submit на форме — редирект — параметры в урл сохраняются.

S>Тут сессия вообще ни в каком месте не нужна.

use case:
1. юзер меняет параметры на открытой форме репорта,
2. возвращается на страницу ReportSelector
...
тут клиент хочет, что бы в 2 были выбранные параметры из 1, что вообще не реально... хмм... Надо бы об этом побольше подумать.

Здравствуйте, B0rG, Вы писали:
BG>Сделано по религии asp.net: методы вызываются по "эвентам" OnButtonClick.
Конкретно это — хреновая религия. Вы имеете избыточный POST и все проблемы связаны с неверным применением хорошего инструмента. Но сейчас у меня нет времени про это детально рассказывать.

BG>т.е. в ответ на Get мы преселектим инпуты
BG>В _OnButtonClick мы меняем значения контролей
BG>В true == Page.IsPostBack мы собственно показываем данные

BG>т.е. изменение состояния контролей регистрируется только в _OnButtonClick

BG>>>Юзабилити, конечно, будет кошмарным, но другого варианта я пока что не вижу.
S>>Почему не сделать самый простой вариант: делать action="" в мини-форме? Если в ней нужны не все параметры из "большого" ReportSelector, то недостающие нужно просто отдать в виде input type=hidden.

BG>интересная идея надо бы посмотреть. У меня получалось так:
BG>открываем новую страницу через GET, в урл параметры
BG>давим Submit на форме — редирект — параметры в урл сохраняются.

S>>Тут сессия вообще ни в каком месте не нужна.

BG>use case:
BG>1. юзер меняет параметры на открытой форме репорта,
BG>2. возвращается на страницу ReportSelector
BG>...
BG>тут клиент хочет, что бы в 2 были выбранные параметры из 1, что вообще не реально... хмм... Надо бы об этом побольше подумать.
Ага, надо.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, B0rG, Вы писали:
BG>>Сделано по религии asp.net: методы вызываются по "эвентам" OnButtonClick.
S>Конкретно это — хреновая религия. Вы имеете избыточный POST и все проблемы связаны с неверным применением хорошего инструмента. Но сейчас у меня нет времени про это детально рассказывать.

Твоими бы устами, да мед пить

Да я, в общем-то, тоже не фанат viewstate-event модели asp.net, но это позволяет джуниорам быстро лепить кое-как работающий код, который я потом оптимизирую в особо медленных местах.

Переписывать полностью asp.net аппликухи только потому, что у нас view-state дает пару лишних килобайт на каждый запрос тут никто не будет. Потому как:
* программеры дорогие
* интернеты дешевые

Практически везде adsl 3M/400K чего вполне хватает для нормальной работы. Оптимизировать каждый эвент будет стоить еще порядка 10 штук в месяц за программера и этим мало кто занимается, потому как не выгодно.

Здравствуйте, B0rG, Вы писали:
BG>Переписывать полностью asp.net аппликухи только потому, что у нас view-state дает пару лишних килобайт на каждый запрос тут никто не будет. Потому как:
BG>* программеры дорогие
BG>* интернеты дешевые
Проблема не столько в дороговизне интернета, сколько в том, что такая модель приводит к unusable приложениям. Вы никак не скомпенсируете доллары, украденные из кармана ваших клиентов — именно они теряют минуты на неудобстве интерфейса, которые складываются в часы.

Спасает вас пока только то, что разработка веб приложений в целом находится на очень низком уровне. Подавляющее большинство веб сайтов катастрофически неудобны; поэтому конкуренция пока невысока. Со временем этот сектор будет развиваться, и желательно как можно раньше приучиться делать приложения, которые не пытаются противоречить всем метафорам интернета, а следуют им.
BG>Практически везде adsl 3M/400K чего вполне хватает для нормальной работы. Оптимизировать каждый эвент будет стоить еще порядка 10 штук в месяц за программера и этим мало кто занимается, потому как не выгодно.
Крайне рекомендую как можно быстрее ознакомиться с MVC Framework из ASP.NET 3.5. Это — правильный способ делать приложения на ASP.NET.

Здравствуйте, Sinclair, Вы писали:

S>Проблема не столько в дороговизне интернета, сколько в том, что такая модель приводит к unusable приложениям. Вы никак не скомпенсируете доллары, украденные из кармана ваших клиентов — именно они теряют минуты на неудобстве интерфейса, которые складываются в часы.

S>Спасает вас пока только то, что разработка веб приложений в целом находится на очень низком уровне. Подавляющее большинство веб сайтов катастрофически неудобны; поэтому конкуренция пока невысока. Со временем этот сектор будет развиваться, и желательно как можно раньше приучиться делать приложения, которые не пытаются противоречить всем метафорам интернета, а следуют им.

S>Крайне рекомендую как можно быстрее ознакомиться с MVC Framework из ASP.NET 3.5. Это — правильный способ делать приложения на ASP.NET.

Вы вообще читаете, что пишете?

* прозрачные намеки на доллары, украденные из кармана моих клиентов, видимо мной
* не прозрачные намеки на мой непрофессионализм
* повелительные наклонения

Вас где учили разговаривать с людьми?

Здравствуйте, B0rG, Вы писали:
BG>Вы вообще читаете, что пишете?
Нет, не успеваю.
BG>* прозрачные намеки на доллары, украденные из кармана моих клиентов, видимо мной
Ну почему лично вами. Надо полагать, теми джуниорами, которые не знают, как правильно писать веб-приложения.
BG>* не прозрачные намеки на мой непрофессионализм
Я про профессионализм ничего не говорил. Я пишу исключительно про то, что бывают неправильные веб-приложения, а бывают правильные.
Вы не расстраивайтесь — в мире не так много людей, которые могут понять, чем первые отличаются от вторых.
BG>* повелительные наклонения
Это где? Не вижу ни одного повелительного наклонения. Может, пропустил где? На всякий случай напомню, что "я рекомендую ..." — это не повелительное наклонение. Повелительное наклонение — это "иди учи ....".
BG>Вас где учили разговаривать с людьми?
Спецкурс.
Основан на книгах "How to talk dirty and influence people", "Man-manipulator" и других, которых я уж не помню.

Здравствуйте, Sinclair, Вы писали:

BG>>Вы вообще читаете, что пишете?
S>Нет, не успеваю.


Я не обижаюсь на несовершенство людей на интернете, более того меня это вообще никак не парит.

Что до приложений, то вот здесь и причина наших несогласий: для меня не бывает "правильных" и "неправильных" приложений с точки зрения используемых технологий. Я оцениваю приложения по тому, как они выполняют поставленную клиентами задачу, с ограничениями на трафик, ошибки и аптайм. В рамках бюджета и с ограниченным количеством ресурсов.

Производство софта как и его качество (разумное и допустимое) зависит от имеющихся на проекте ресурсов и их распределения между разными по важности задачами проекта.

В предыдущих постах я рассказывал о реально поставленных задачах с определенными требованиями: поддержка, целостность данных, аутентикация, и о способах их решения на проекте, в котором я работал.

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

Ибо ну на фига мне в топологии: Веб Сервер картинок + ДБ Сервер и задаче "не таскать видео и картинки с БД Сервера на Веб Сервер в ответ на каждый запрос", усложнять топологию добавляя Reverse Proxy Server перед сервером картинок и настраивать на нем http хидеры. Какую из моих и клиентских проблем это решает? Ну смешно уже ей богу.

И под конец, кроме несколько overengineered решений, я еще должен выслушивать критику в формате: выбранная модель программирования приводит к unusable приложениям и крадет доллары и часы из карманов клиентов. И советы выучить очередную overbloated систему паттернов.

Тут уже не то что бы смешно, а немного грустно от абсурдности ситуации: ну каким образом программная модель связывания кнопки на форме с кодом за формой (asp.net event base model), за счет пары тройки килобайт во вью стейте (я не удержусь и процитирую еще):

сколько в том, что такая модель приводит к unusable приложениям. Вы никак не скомпенсируете доллары, украденные из кармана ваших клиентов — именно они теряют минуты на неудобстве интерфейса, которые складываются в часы.

Я ваши остальные посты видел, выж вроде человек неглупый, но здесь я конкретно недоумеваю, что вас сподвигло нести такую феерическую чушь. Невосприятия связывания asp.net event модели чтоли? Get over it!

Здравствуйте, B0rG, Вы писали:
BG>Я не обижаюсь на несовершенство людей на интернете, более того меня это вообще никак не парит.
Весьма похвальная позиция.
BG>Что до приложений, то вот здесь и причина наших несогласий: для меня не бывает "правильных" и "неправильных" приложений с точки зрения используемых технологий. Я оцениваю приложения по тому, как они выполняют поставленную клиентами задачу, с ограничениями на трафик, ошибки и аптайм. В рамках бюджета и с ограниченным количеством ресурсов.
Еще более похвальная позиция. Я с ней совершенно согласен.
Но дело в том, что буквальное следование ей зачастую затруднено. Зависимость трафика, ошибок и аптайма от принятых архитектурных решений редко поддается аналитическому определению.

Поэтому реальные разработчики принимают решение эвристическим способом. Заранее предсказать точные значения характеристик не удастся, но в 99% случаев можно как минимум гарантировать некоторое улучшение.
BG>Производство софта как и его качество (разумное и допустимое) зависит от имеющихся на проекте ресурсов и их распределения между разными по важности задачами проекта.

BG>В предыдущих постах я рассказывал о реально поставленных задачах с определенными требованиями: поддержка, целостность данных, аутентикация, и о способах их решения на проекте, в котором я работал.

BG>Вы, в свою очередь, предлагали технологически более сложные решения, которые
BG>* с технической точки зрения решали совсем не ту проблему которую ставил я
BG>* требовали наличия дополнительных ресурсов (которых проект себе позволить не мог, по разным причинам)
BG>* не приносили клиенту никакой дополнительной ценности

BG>Ибо ну на фига мне в топологии: Веб Сервер картинок + ДБ Сервер и задаче "не таскать видео и картинки с БД Сервера на Веб Сервер в ответ на каждый запрос",
Начнем с того, что такой задачи у вас не было. Была задача обеспечить performance, traffic и т.п. Это вы решили (пока неясно, почему), что bottleneck — в СУБД.
BG>усложнять топологию добавляя Reverse Proxy Server перед сервером картинок и настраивать на нем http хидеры.
Еще раз объясняю: усложнять топологию необязательно. Правильное решение увеличивает свободу. Оно может дать ускорение немедленно, безо всяких затрат на кэш.
А может и не дать — нужно смотреть логи и анализировать соотношение 200 к 304.
Далее можно масштабировать систему, не заморачиваясь переписыванием кода.
BG>Какую из моих и клиентских проблем это решает? Ну смешно уже ей богу.
Ничего смешного в этом нету. Есть банальная техническая безграмотность: вместо того, чтобы изучить готовые технические решения, изобретаются свои велосипеды.

BG>И под конец, кроме несколько overengineered решений, я еще должен выслушивать критику в формате: выбранная модель программирования приводит к unusable приложениям и крадет доллары и часы из карманов клиентов. И советы выучить очередную overbloated систему паттернов.
Вообще-то overbloated система паттернов в данном случае — это как раз серверные формы ASP.NET, с их постбеками и вьюстейтами.
А вот MVC из ASP.NET 3.5 — стройная и простая система. Это то, как надо было писать ASP.NET с самого начала. Она позволяет писать компактный и надежный код, а также получать приложения, более удобные для конечного пользователя.

BG>Тут уже не то что бы смешно, а немного грустно от абсурдности ситуации: ну каким образом программная модель связывания кнопки на форме с кодом за формой (asp.net event base model), за счет пары тройки килобайт во вью стейте (я не удержусь и процитирую еще):
BG>

сколько в том, что такая модель приводит к unusable приложениям. Вы никак не скомпенсируете доллары, украденные из кармана ваших клиентов — именно они теряют минуты на неудобстве интерфейса, которые складываются в часы.

BG>Я ваши остальные посты видел, выж вроде человек неглупый, но здесь я конкретно недоумеваю, что вас сподвигло нести такую феерическую чушь. Невосприятия связывания asp.net event модели чтоли? Get over it!
Вообще-то я достаточно хорошо разбираюсь в модели связывания евентов ASP.NET. Есть, конечно, некоторые темные уголки, которые я не до конца исследовал, но ничего принципиально непонятного там нет.

К моему глубокому сожалению, это не феерическая чушь, а суровая реальность. Я не так много знаю публичных сервисов на ASP.NET, где мог бы продемонстрировать пример, но есть достаточно известный в узких кругах сервис tokidoki.ru, который написан в полном соответствии с типичными паттернами postback-oriented программирования.

Если бы его проектировали компетентные люди, то основной его сервис выглядел бы совсем по другому.
Основной сервис — это "дай мне список лотов на предстоящие аукционы, удовлетворяющих таким-то критериям".
Как проектируют такой сайт компетентные разработчики?
1. Упаковывают все параметры запроса в URL и отдают его в ответ на запрос GET.
2. Не забывают обработать if-modified-since (что очень легко сделать, т.к. лоты поступают в порядке очереди, и всегда известно, когда поступил последний)
Почему они так делают?
Потому что это позволяет пользователю
а) поставить закладку на поисковый запрос, и одним кликом получать доступ к данным
б) очень быстро и эффективно получать обновление

Как это проектируют реальные пацаны?
Конечно же, они делают получение результата через POST, при этом часть данных лежит в сессии. Чтобы сделать этот POST, нужно сначала открыть форму весом в полмегабайта.
Для решения проблемы закладок они реализовали свою систему "сохраненных запросов" на стороне сервера. Чтобы открыть сохраненный запрос, нужно опять же обновить эту же кошмарную форму. Кэширование везде запрещено, потому что это всё, что они умеют делать с кэшированием. В итоге, чтобы посмотреть список лотов и убедиться что новых не поступило, я трачу 10 минут и 3 мегабайта трафика. А мог бы — 10 секунд и килобайт трафика.

Вот оно — воровство моего времени и денег. Че там насчет get over it?

Здравствуйте, Sinclair, Вы писали:

BG>>Что до приложений, то вот здесь и причина наших несогласий: для меня не бывает "правильных" и "неправильных" приложений с точки зрения используемых технологий. Я оцениваю приложения по тому, как они выполняют поставленную клиентами задачу, с ограничениями на трафик, ошибки и аптайм. В рамках бюджета и с ограниченным количеством ресурсов.
S>Еще более похвальная позиция. Я с ней совершенно согласен.
S>Но дело в том, что буквальное следование ей зачастую затруднено. Зависимость трафика, ошибок и аптайма от принятых архитектурных решений редко поддается аналитическому определению.

С вами нельзя не согласиться

Только тут есть два тонких момента:

1) Я решал свою задачу оптимизации трафика между БД Сервером и Файл Сервером по методу: максимум оптимизации, за минимум времени. Мое решение меня и моих коллег в общем-то устроило. Было бы больше времени сделали бы поумнее.

2) Вы привели хороший пример, но я бы смотрел на него по другому:

Это не ошибка разработчиков, это ошибка архитекторов проекта. В частности неправильно составленные требования к high-volume traffic pages. Вы, наверняка, согласитесь, что в любой аппликухе есть куски, которые используются часто, и есть куски, что используются редко. На "редких" кусках можно оставить Button_OnClick() схему обработки, ценой дешевого пост-бека и пары кил вью стейта. "Частые" куски, стоит оптимизировать, тут спорить не о чем.

Между нами девочками говоря, я и сам не особо доволен этой event based моделью, но в большинстве случаев ее использовать можно. Рефакторить ее тоже не особо сложно, беда в том, что джуниорам эту работу доверить как правило нельзя: такие вещи требуют не только знания, но и ответственности с известной долей педантизма.

На MVC будем посмотреть однозначно, счас как раз пишу песочницу на asp.net 3.5 с linq, надо будет ее туда включить. У меня просто есть некоторое недоверие ко всему, что называется MVC

Здравствуйте, B0rG, Вы писали:
BG>С вами нельзя не согласиться
Можно
BG>Только тут есть два тонких момента:

BG>1) Я решал свою задачу оптимизации трафика между БД Сервером и Файл Сервером по методу: максимум оптимизации, за минимум времени. Мое решение меня и моих коллег в общем-то устроило. Было бы больше времени сделали бы поумнее.
Ну, про задачу оптимизации трафика между СУБД и файловой системой я ничего не говорил. Вполне может быть, что ваше решение 100% оптимально. Я говорил о том, что в контексте веб приложения файловая система может участвовать как решение, а не как задача. И я считаю это решение спорным (есть ситуации, в которых оно будет оправдано; в среднем это не так).
BG>2) Вы привели хороший пример, но я бы смотрел на него по другому:
BG>Это не ошибка разработчиков, это ошибка архитекторов проекта. В частности неправильно составленные требования к high-volume traffic pages. Вы, наверняка, согласитесь, что в любой аппликухе есть куски, которые используются часто, и есть куски, что используются редко. На "редких" кусках можно оставить Button_OnClick() схему обработки, ценой дешевого пост-бека и пары кил вью стейта. "Частые" куски, стоит оптимизировать, тут спорить не о чем.
Я не согласен с этой позицией. Она подразумевает, что сначала применяются откровенно плохие решения, а потом мы выделяем ограниченный бюджет на их исправление.

Почему нельзя сразу сделать по уму?
Вот альтернатива моему примеру про токидоки.
Вы что, думаете, что разработчики pravto потратили прямо-таки намного больше усилий? Скорее наоборот — им не пришлось решать искусственно созданные проблемы.

BG>Между нами девочками говоря, я и сам не особо доволен этой event based моделью, но в большинстве случаев ее использовать можно. Рефакторить ее тоже не особо сложно, беда в том, что джуниорам эту работу доверить как правило нельзя: такие вещи требуют не только знания, но и ответственности с известной долей педантизма.

BG>На MVC будем посмотреть однозначно, счас как раз пишу песочницу на asp.net 3.5 с linq, надо будет ее туда включить. У меня просто есть некоторое недоверие ко всему, что называется MVC
Ну, я бы назвал ее как-то по-другому, но я не работаю в ASP.NET Team. Почитай блог Скотта Гатри про ASP.NET и конкретно про MVC — там очень убедительные примеры есть.

Здравствуйте, B0rG, Вы писали:

BG>Это не ошибка разработчиков, это ошибка архитекторов проекта. В частности неправильно составленные требования к high-volume traffic pages. Вы, наверняка, согласитесь, что в любой аппликухе есть куски, которые используются часто, и есть куски, что используются редко. На "редких" кусках можно оставить Button_OnClick() схему обработки, ценой дешевого пост-бека и пары кил вью стейта. "Частые" куски, стоит оптимизировать, тут спорить не о чем.
Наверное, вы считаете, что отличный выход в системе применять два решения.
Не думаю что с точки зрения поддержки это будет выглядеть хорошо.

BG>Между нами девочками говоря, я и сам не особо доволен этой event based моделью, но в большинстве случаев ее использовать можно. Рефакторить ее тоже не особо сложно, беда в том, что джуниорам эту работу доверить как правило нельзя: такие вещи требуют не только знания, но и ответственности с известной долей педантизма.
А в чем недовольство event based моделью?
Можно услышать конкретные проблемы?
Может быть их можно решить без перехода на MVC


BG>На MVC будем посмотреть однозначно, счас как раз пишу песочницу на asp.net 3.5 с linq, надо будет ее туда включить. У меня просто есть некоторое недоверие ко всему, что называется MVC
Странно, с чего у вас такое?

Здравствуйте, Sinclair, Вы писали:

S>Я не согласен с этой позицией. Она подразумевает, что сначала применяются откровенно плохие решения, а потом мы выделяем ограниченный бюджет на их исправление.

S>Почему нельзя сразу сделать по уму?
S>Вот альтернатива моему примеру про токидоки.
S>Вы что, думаете, что разработчики pravto потратили прямо-таки намного больше усилий? Скорее наоборот — им не пришлось решать искусственно созданные проблемы.

Гы, правильные вопросы задаете, товарищ (с)
Беда в том, что у меня нет на них правильных ответов.

Расскажу вам лучше байку с одного из моих последних интервью в HP Financial Services: сидим базарим с проджект мэном и арком за жизнь и архитектуру. Попутно я бросаю фразу о том, что все производство софта суть набор компромиссов и начинаем за здравие, кончаем за упокой. Чем дольше лайфсайкл тем больше компромиссов. Завершаю фразой: как бы я хотел работал над проектом с самого начала в толковой группе, с правильно построенной архитектурой и т.д... Оба собеседника в один голос: если найдешь такой проект обязательно позвони нам

В общем, честно говоря, я не знаю "почему нельзя сделать сразу по уму". Народ почему то не делает. Но меня это вполне устраивает: я могу прийти, посмотреть на проект, и сказать "за 6 месяцев мы это релизим, мне нужно a, b и с". И мы релизим за 5 + месяц на поддержку и кое-какую оптимизацию, а потом я иду в другую контору