Здравствуйте, Calabon, Вы писали:
Ужос. Ужос-ужос.
Нельзя так писать. И задача, и решение, и проблема которую вы получили, и слова, которыми вы это описываете — всё это беспросветный ужос.

Зачем вам параметры сабмита в сессии? Вы вообще понимаете, что такое веб? Чем отличается Get от Post? Что такое Redirect? Что такое сессия, зачем она нужна, и как она работает? Как кэшируются запросы, и почему?

Поставьте fiddler2.com — это первый шаг в веб-разработке. Пока вы не начнете понимать, что там пишется в лог при навигации по вашему сайту, всё остальное лишено смысла.

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

C>Что значит зачем? Это очень даже избитая тема в инете.
Она избита людьми, у которых отсутствует часть мозга, необходимая для разработки веб-приложений.
C>Нужно запретить вторичное выполнение действий по обработке урл.
Нужно просто проектировать нормально, и не будет никаких запретов.
Основы веб: запросы GET не должны иметь побочных эффектов.
Повторяйте это на ночь по шестьсот раз, до просветления.
Тогда при "обработке урл" вторичное выполнение ничем не будет грозить. А освоив хидеры Expiration; Last-modified; If-modified-since, if-none-match, вы получите офигенный прирост производительности в них.

После этого, в принципе, можно понять, что побочные эффекты можно делать только при помощи метода POST. Обратное также верно: POST стоит использовать только в том случае, если у запроса будут побочные эффекты. Тогда жизнь станет легкой и приятной. Останется только две проблемы:
1. Быстрое двукратное нажатие на кнопку Send, что приводит к удваиванию запроса
2. Back после Send и Forward c "Retry". Что тоже приведет к удваиванию запроса.

Вторая проблема лечится редиректом после поста — 302. Редирект вызывает смену глагола на GET, а POST исчезает из history браузера.
Первую проблему лечат разными способами. Можно поискать в гугле по словам Post Exactly Once; можно просто в OnSubmit формы дизаблить кнопку Send.

C>Проста туча вапросов к разработчикам ASP.NET почему может терятся сессия ниставо ниссиво.
Осваивайте фиддлер, и сессии пребудут с вами. Кстати, сессия — вообще зло, если что. Она не дает делать высокопроизводительные приложения. Сходите на google.com, подумайте, почему гугл не использует сессии.

S>>Чем отличается Get от Post? Что такое Redirect? Что такое сессия, зачем она нужна, и как она работает? Как кэшируются запросы, и почему?
C>Очень интересно ваше мнение о этом всём. Не знаю только одного — как кэшируются запросы.. и па каким таким вапросам ниставо ниссиво...
Ну вот кэширование респонсов обычно помогает понять, зачем делать всё правильным способом, а неправильным — не делать.
C>Вопсчем ты какой та бред написал.. тупа залашыл меня бес причины.. а лучшеп па делу.
С причиной.

C>Использовал сниффер. То что сообщение Page_Load не вызывается я уверен. Редирект происходит — 302 Found.

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

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

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

Здравствуйте, 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?

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

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

Здравствуйте, C...R...a...S...H, Вы писали:

CRA>Так тогда, что вы говорили по поводу того, что разработка дороже поддержки?

потому что я не упомянул еще 10-20 релиз проджект тимов в каждой в среднем по 10 — 15 человек, которые занимаются собственно разработкой функциональности релиза. Затраты на саппорт на фоне затрат на проджект команды и тест команды в релизе, ничтожны.

Что до разных методов, то я работал в разных компаниях и смотрел по сторонам. Во взрослых конторах стабильность и качество системы как правило имеет приоритет. В детских садах, приоритет имеют сроки. То, что я называю Customer Driven Testing, т.е. мы фиксим только те баги, которые находит кастомер. Это не смешно, конечно же, но тем не менее — реальность.

CRA>При первом способе во вселенной существуют сильные программеры которым нравиться сапорт (мне кажется это фантастика ) А вот во втором случае таких программеров не существует.

Никто не говорил, что им нравится саппорт У них другие бенефиты.

CRA>Так вот и получается что своими решениями добавить парачку архитектурных решения в один проект, вы закапываете всю каманду, потому что проект превращается, превращается проект в жуткого монстра, который содержит в себе несколько архитектурных решений аля:
CRA>Половина объектов домена использует Lazy load, а другая половине нет.
CRA>И народ, который сам же и писал эту систему уже не в силах что то поменять, и поэтому уходит в другие проекты.

Я не считаю это большим грехом. Статические данные вплоне могут грузиться как и ленивым способом так и "все сразу". Конечно, было бы хорошо, если бы грузились одинаковым, но на некотором этапе развития системы это уже не возможно. Называется organic growth.

CRA>Отлично!!!
CRA>Я затеял этот спор только для того, что бы узнать хоть парачку таких проблем.
CRA>Поделитесь пожалуйста.

Я подписываю NDA, который в частности запрещает мне обсуждать детали архитектуры. А проблемы когда текущая архитектура сильно усложняет процесс, кроются как раз в этих самых деталях.

Хотя ладно: имеем модную архитектуру с nettiers orm, enterprise library, infragistics controls. Административный запрет на прямой доступ к базе. Во время первого бета релиза клиенту выясняется, что
1) при 5000+ записей в основных словарях (девелоперы использовали не больше трех записей типа Клиенты, Юзера, Продукты), все списки начинают тормозить, отжирая порядка 700 метров после 5 кликов на юае, да и грузяться порядка 100 секунд.
2) при загрузке реальных продуктов (там 4 поля типа текст, полный вес объекта может превышать 8 метров) выяснилось, что на клиента отправляется порядка 10 мегабайт viewState, потому что кто-то очень умный сохраняет этот объект во вью стейт.

Решения:
1)
* профайлером было обнаружено, что infragistics очень любит GetHashCode() метод, который оверлоадиться в энтитях в формате:
GetHashCode() { return property1.ToString + property2.ToString + ... }
Поменяли.

* Для генерации списков nettiers генерит специальные классы типа WebControls, нечитабельные совершенно, к тому же не поддерживающие ничего кроме IEnumerable()
После долгих споров я всех убедил это переписать на ObjectDataSource с прямым ad hoc сиквелом стало серьезно быстрее и память больше не текла. Тут можно было бы сделать еще быстрее, но юай использовал Infragistics контроли с очень богатой написанной функциональностью, переписывать которую вручную времени не было.

2) Хакнули через сохранение ViewState на сервере. Это чревато, конечно, но опять же — не было времени.

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

Как вы и сами понимаете ни я ни мой коллега этот проект видеть больше не хотели

Здравствуйте, B0rG, Вы писали:
Замечание в сторону: на заре своей ASP.NET карьеры имел крайне негативный опыт взаимодействия с инфрагистиками.
То есть, с одной стороны, я в то время вообще не понимал как рендерятся страницы в ASP.NET, что такое viewstate и прочие детали postbackов, а с другой стороны, инфрагистики работали
а) чудовищно медленно в любом варианте и
б) некорректно во многих из вариантов.

После этого я перестал верить в великую силу инфрагистика, и на несколько лет заразился ощущением, что я делаю что-то не то.
Это ощущение стало превращаться в уверенность, когда я начал лучше понимать внутреннее устройство постбеков, а также закономерности поведения хороших веб-приложений.

В итоге понимание того, как надо писать приложения, у меня нашлось, но осадок по отношению к инфрагистику остался. Безотносительно окружающей архитектуры.

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

Здравствуйте, 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.

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

Начитался много примеров, видял что люди постят непонятные вещи на asp.net сайте, итак моя проблема:
Данные на вебформе адресуются с помощью урл, и так же как и всем остальные нет желания чтобы этот линк постоянно торчал в браузера, нужно его удалить.(проверка на постбак не удовлетворяет требованиям)

Алгоритм:
1. достаём из урл нужные параметры
2. сохраняем их в сессию, каждый в отдельный объект
3. делаем редирект на страницу без параметров

после редиректа бряки на страницу не попадают, происходит чтото доужаса странное! Сессия теряется, все значения становятся дефолтными

Response.Redirect("Home.aspx", false);

Но, как только я к редиректу добавлю "?" ("Home.aspx?") или ?whatever, то вызов происходит и сессия присутствует, но при последующем разе приходится это самое whatever поменять на чтонибуть типа whatever2, и я достигаю желаемого результата чередуя их туда сюда. Очень похоже на кэширование, чтото вроде

if (CurrentUrl == this.Url)
{
   ExitAndDoNotFirePageEvents(); // !!!!
}

Самое главное то, что это работало и потом резко перестало (возможно я ставил какие то фиксы например VS SP1), но код один и тот же!

Есть у каво нибудь комментарии по данному вопросу?

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

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

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

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

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

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

Здравствуйте, 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>>Гы, правильные вопросы задаете, товарищ (с)
BG>>Беда в том, что у меня нет на них правильных ответов.
S>У меня есть. "не нужно искать злой умысел там, где для объяснения довольно глупости"

К сожалению все не так просто. Я избегаю обвинять коллег в глупости

BG>>В общем, честно говоря, я не знаю "почему нельзя сделать сразу по уму". Народ почему то не делает.
S>Народ как правило применяет то, к чему приучен.
S>ASP.NET 1.0 был катастрофической вещью. Штука, которая по умолчанию делает максимально плохие решения, воспитала целое поколение людей с травмированным здравым смыслом.
S>К счастью, хотя бы 3.5 подает надежды на лучшее.

Я делал только asp.net 2.0, с 1.1 игрался — у меня есть свой MVC framework с xml+xslt, и ручным процессором query string, но потом просто достало переписывать под него контроли, да и ajax на него не сильно хорошо ложится.

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

Тут бизнес тоже можно понять. Я стою в три-четыре раза больше среднего джуниора, и бизнес считает, что проще нанять трех джуниоров. После года работы, бизнесу становится понятно, что все таки нужен сеньор, т.к. сроки просрочены, проект разваливается на части, все недовольны, ну и т.д. После того как проект сдан острая необходимость во мне отпадает, и я нахожу другой контракт.

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

BG>Здравствуйте, C...R...a...S...H, Вы писали:

BG>>>2) при загрузке реальных продуктов (там 4 поля типа текст, полный вес объекта может превышать 8 метров) выяснилось, что на клиента отправляется порядка 10 мегабайт viewState, потому что кто-то очень умный сохраняет этот объект во вью стейт.
CRA>>Ничего не понятно, что за объект такой.

BG>обычный Продукт с четырьмя текстовыми описаниями, и прочей лабудой. Беда была в форме его редактирования — InfragisticsTabControl с пятью табами, каждый делал что то интересное. Разработчик решил, что самым лучшим способом передавать продукт между табами, будет ViewState. Это, конечно, работало на ура, т.к. девелоперы не заполняли текстовые поля продукта поэтому вес сериализованного продукта был меньше килобайта, и ни кого не волновал. Как только запихали реальные продукты с реальными описаниями, вес сериализованного Продукта увеличился до 8 метров, и стало немного тяжеловато. Опять же проблема прояснилась когда я из дома на это смотрел — на работе толстый канал чуть ли не 2 мега аплоад, там чуток подтормаживало но не сильно, а вот из дома с моими 384Килобитами, 8 метров аплоада на постбаке было уже существенно.

BG>Проблема была еще в том, что начальные разработчики не придерживались философии: глупый юай, умный бакэнд, поэтому большая часть бизнес логики была запихана прямо в aspx страницы, не самым оптимальным способом. Рефакторить этот код было очень тяжело и в некоторых случаях практически не возможно. На полную перепись формы редактирования ушло бы недели три (спеков нет, тестов нет, нихрена нет), а времени уже практически не оставалось.
Так с этого и надо было начинать, проблема одна — кривая архитектура.
И говорить, что ASP.NET Events model is sucks неправельно!


BG>>>Решения:
BG>>>1)
BG>>>* профайлером было обнаружено, что infragistics очень любит GetHashCode() метод, который оверлоадиться в энтитях в формате:
BG>>>GetHashCode() { return property1.ToString + property2.ToString + ... }
BG>>>Поменяли.
CRA>>Странно я всегда думал что возвращаемое значение у GetHashCode() Int32

BG>ну значит таким образом
BG>GetHashCode() {return property1.ToString().GetHashCode() + property2.ToString().GetHashCode() ... }
BG>я уже честно сказать не помню, дело было в сентябре Суть в том, что GetHashCode для ентитей считался как суммарный нашкод всех мемберов (а те в свою очередь тоже могли быть сложными объектами). ToString() там точно был, потому что именно по ToString() я его и нашел в профайлере: у нас 5000 продуктов в базе, на гриде отображается страница в 20 продуктов, а при этом у меня в профайлере 3 000 000 вызовов ToString(). понятное дело WTF?! Переделали, что бы возвращал EntityID, т.к. и продукты и юзера и клиенты имеют primary key, который в общем то и определяет их идентичность.
Интересно, в одном случае инфраджистик в другом EntityID, как я понимаю проблемы были с доменными объектам

CRA>>Интересно кончено, но по тому что вы написали я ничего не могу сказать конкретного, так как мне лично ничеге не понятно, с nettiers так что умываю руки

BG>Я надеялся, что вам будет понятно, что неттиерс использовать не стоит
Посмотрим, жизнь она такая...

BG>>>Как вы и сами понимаете ни я ни мой коллега этот проект видеть больше не хотели
CRA>>Так получается у вас как в детском саду?

BG>В той конторе был деццкий сад, не без этого. В этой конторе не деццкий сад, но архитекрурные проблемы все равно есть.
Без архитектурных проблем никуды.
Но я знаю одно — несколько архитектурных решений в одном проекта это самое плохое что может быть!

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

S>В итоге понимание того, как надо писать приложения, у меня нашлось, но осадок по отношению к инфрагистику остался. Безотносительно окружающей архитектуры.

Все верно.

Инфрагистики достаточно тяжелая штука. Я и сам не фанат. Но тут есть несколько но:
*) клиент хотел rich functionality. Если бы девелоперы это делали руками, не применяя инфрагистик, у них ушло бы в 3 раза больше времени и 10 раз больше багов.
*) Некоторые вещи они позволяют делать очень быстро и красиво: например экспорт грида в эксель — я думал, что пропарюсь пол-дня не меньше (после моих предыдущих экспериментов), а удалось сделать за 15 минут.

Если согласиться жить с этими недостатками, понимая при этом, что мы приносим в жертву, то инфрагистиками вполне себе можно жить

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

C>Есть у каво нибудь комментарии по данному вопросу?
C>

Посмотри сниффером, какие заголовки приходят браузеру с этой страницы (на тему кеширования). М.б., последующего запроса нет ВООБЩЕ ? (ну или бряк в page load поставь)

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

C>Самое главное то, что это работало и потом резко перестало (возможно я ставил какие то фиксы например VS SP1), но код один и тот же!
C>Есть у каво нибудь комментарии по данному вопросу?

А информация о сессии не в query string храниться? если да, то переставь на куки файл

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

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

C>>Самое главное то, что это работало и потом резко перестало (возможно я ставил какие то фиксы например VS SP1), но код один и тот же!
C>>Есть у каво нибудь комментарии по данному вопросу?

V>А информация о сессии не в query string храниться? если да, то переставь на куки файл

Если б у него было настроено хранение ключа сессии в query string, тогда б она была пустая и с ?whatever/?whetever2
imho тут что-то другое...

BTW: если ключ сессии не в query string, то как раз в куки хранится. А уже по этому ключу всю остальную инфу можно и на сервере хранить. Так что принципиальной разницы быть не должно

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

C>Начитался много примеров, видял что люди постят непонятные вещи на asp.net сайте, итак моя проблема:

У нас была похожая проблема. Нужно было очистить QueryString, но Response.Redirect нам не помогал, тк. при открытии ссылки из других приложений (например если это ссылка в письме в Аутлуке) редирект делался этим приложением (Аутлуком), а не IE. Соотвественно сессия ТЕРЯЛАСЬ.

Поэтому редирет сделали на Javascript:

private void JavascriptRedirect()
{
  Response.Clear();
  string script = "";
  script += "<script type=\"text/javascript\">\r\n document.location = \"default.aspx\";\r\n </script>\r\n";
  Response.Write(script);
  Response.End();
}

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

S>Здравствуйте, Calabon, Вы писали:
S>Ужос. Ужос-ужос.
S>Нельзя так писать. И задача, и решение, и проблема которую вы получили, и слова, которыми вы это описываете — всё это беспросветный ужос.

Да знаю я это. вапще всйо ужос!

S>Зачем вам параметры сабмита в сессии? Вы вообще понимаете, что такое веб?

Что значит зачем? Это очень даже избитая тема в инете. Нужно запретить вторичное выполнение действий по обработке урл. Проста туча вапросов к разработчикам ASP.NET почему может терятся сессия ниставо ниссиво.

S>Чем отличается Get от Post? Что такое Redirect? Что такое сессия, зачем она нужна, и как она работает? Как кэшируются запросы, и почему?

Очень интересно ваше мнение о этом всём. Не знаю только одного — как кэшируются запросы.. и па каким таким вапросам ниставо ниссиво...
Вопсчем ты какой та бред написал.. тупа залашыл меня бес причины.. а лучшеп па делу.

S>Поставьте fiddler2.com — это первый шаг в веб-разработке. Пока вы не начнете понимать, что там пишется в лог при навигации по вашему сайту, всё остальное лишено смысла.

Использовал сниффер. То что сообщение Page_Load не вызывается я уверен. Редирект происходит — 302 Found.

Насколько я понял из обсуждения вы боретесь с пользовательской перегрузкой страницы и хотите избавится от сообщения "Перепослать данные ещё раз?"

Поддерживаю Антона целиком и полность.

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

C>Что значит зачем? Это очень даже избитая тема в инете. Нужно запретить вторичное выполнение действий по обработке урл. Проста туча вапросов к разработчикам ASP.NET почему может терятся сессия ниставо ниссиво.

тема действительно избитая. патерн даже сть такой:

здесь и здесь

цитата:

The Mantra
PRG pattern can be rephrased like this:

Never show pages in response to POST 
Always load pages using GET
Navigate from POST to GET using REDIRECT 

Repeat these lines before going to bed.

НО нигде там нет про то что нужно в сессию при этом данные писать, и/или чистить QueryString
наоборот. обычно наоборот — редирект делается со всей нужной информацией.

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

S> Кстати, сессия — вообще зло, если что. Она не дает делать высокопроизводительные приложения. Сходите на google.com, подумайте, почему гугл не использует сессии.

Можно, кстати, какие-нибудь указатели на то, как жить без сессии? Потому как мы бы с удовольствием, но не умеем пока.

Здравствуйте, Maxim Golov, Вы писали:
MG>Можно, кстати, какие-нибудь указатели на то, как жить без сессии? Потому как мы бы с удовольствием, но не умеем пока.
Попробуйте что-то почитать о ViewState & Page Life Cyrcle

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

S>Основы веб: запросы GET не должны иметь побочных эффектов.
S>Повторяйте это на ночь по шестьсот раз, до просветления.
S>Тогда при "обработке урл" вторичное выполнение ничем не будет грозить. А освоив хидеры Expiration; Last-modified; If-modified-since, if-none-match, вы получите офигенный прирост производительности в них.

Это очень хорошее замечание. При необходимости разработки высокопроизводительных приложений обязательно буду использовать информацию из HTTP Headers. Но в моём случае это просто одна страница, которая в очень короткие сроки должна заработать.(максимальное кол-во одновременных пользователей человек 5)

S>После этого, в принципе, можно понять, что побочные эффекты можно делать только при помощи метода POST. Обратное также верно: POST стоит использовать только в том случае, если у запроса будут побочные эффекты. Тогда жизнь станет легкой и приятной. Останется только две проблемы:
S>1. Быстрое двукратное нажатие на кнопку Send, что приводит к удваиванию запроса
S>2. Back после Send и Forward c "Retry". Что тоже приведет к удваиванию запроса.

Мне это известно, но опять же повторяю, что требуемый функционал разрешает мне сделать по — другому.
Это линк это просто что то вроде view state для страницы, только основной функционал сделал на AJAX и поэтому действия выполняются на странице после её загрузки.

S>Вторая проблема лечится редиректом после поста — 302. Редирект вызывает смену глагола на GET, а POST исчезает из history браузера.
S>Первую проблему лечат разными способами. Можно поискать в гугле по словам Post Exactly Once; можно просто в OnSubmit формы дизаблить кнопку Send.

Чего мне действительно не хватает это подобного 307 Temporary, но не preserve POST method, а чтоб частично preserve Query String и preserve Form Data (но это мечты не к изменению стандарта HTTP)

S>Осваивайте фиддлер, и сессии пребудут с вами. Кстати, сессия — вообще зло, если что. Она не дает делать высокопроизводительные приложения. Сходите на google.com, подумайте, почему гугл не использует сессии.

Как я говорил, сниффер использую. Да, согласен, сессия это зло — расширяемость приложения сводится к нулю, но в данном случае позволяю сибе
для быстроты эксперимента сохранить промежуточные данные в сессию. Всё это вообщем очень хорошо... всё достаточно понятно, что когда использовать... Почему же вдруг запросы начали кэшироваться..? Я добивался таких результатов путём вызова редиректа внутри кода на туже страницу при постбэке — Page_Load уже не вызывается, выполняется метод GET к странице и никого не интересует, что требуется preserve POST, код:

Response.Redirect("CurrentPage.aspx"); 
// или
Response.Redirect("CurrentPage.aspx", false); // с сайта разработчиков ASP.NET узнал что ThreadAbortExecution уничтожает cookie c seesionId
// т.е. Response.End() не вызывается, что некоторым помогало
// что аналогично 
Response.ResponseLocation = "CurrentPage.aspx";
Response.StatusCode = 307;

Любой вызов приводит к потере сессии в случае постбака, т.е. к кэшированию страницы... мой выход добавление рандомного числа к ссылке.
Всё понятно с проектированием, и что так лучше не делать, проста неочевидные проблемы, когда пытаешься сделать как проще.
Что думаешь по этому поводу?

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

MG>>Можно, кстати, какие-нибудь указатели на то, как жить без сессии? Потому как мы бы с удовольствием, но не умеем пока.
N>Попробуйте что-то почитать о ViewState & Page Life Cyrcle

Можно подробнее — как VIEWSTATE и знание Page Lifecycle поможет обойтись без того, например, чтобы хранить редактируемый юзером бизнес-объект в Session (предположим, что мы уже смирились и решили, что для аутентикации будем использовать куки. Но бизнес-объект в куки не влезет).

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

MG>Можно подробнее — как VIEWSTATE и знание Page Lifecycle поможет обойтись без того, например, чтобы хранить редактируемый юзером бизнес-объект в Session (предположим, что мы уже смирились и решили, что для аутентикации будем использовать куки. Но бизнес-объект в куки не влезет).
Начать, наверное, стоит с того, что viewstate — это зло. По тем же, в принципе, причинам — используя viewstate, вы отказыааетесь от адресуемости.
Впрочем, для сценария "редактирование бизнес-объекта" viewstate вполне подойдет, поскольку вряд ли кто-то захочет поставить букмарк "в середину" процесса редактирования.

Использовать для этого сессию — крайне плохое решение.
1. Что будет, если пользователь вышел покурить, а его сессия протухла? Теряем все сделанные изменения?
2. Что будет, когда вы удлините время жизни сессии, и одновременно в сессии будут лежать тысячи бизнес-объектов?
3. Что будет, когда один пользователь попытается поредактировать сразу два бизнес-объекта?

Viewstate масштабируется гораздо лучше.

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

C>Что думаешь по этому поводу?
Думаю, что моих телепатических талантов не хватает, чтобы понять, в чем именно проблема. Я своё мнение написал, а в какой строке у тебя ошибка, мне отсюда не видно.

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

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

C>>Что значит зачем? Это очень даже избитая тема в инете.
S>Она избита людьми, у которых отсутствует часть мозга, необходимая для разработки веб-приложений.
C>>Нужно запретить вторичное выполнение действий по обработке урл.
S>Нужно просто проектировать нормально, и не будет никаких запретов.
S>Основы веб: запросы GET не должны иметь побочных эффектов.
S>Повторяйте это на ночь по шестьсот раз, до просветления.
S>Тогда при "обработке урл" вторичное выполнение ничем не будет грозить. А освоив хидеры Expiration; Last-modified; If-modified-since, if-none-match, вы получите офигенный прирост производительности в них.

S>После этого, в принципе, можно понять, что побочные эффекты можно делать только при помощи метода POST. Обратное также верно: POST стоит использовать только в том случае, если у запроса будут побочные эффекты. Тогда жизнь станет легкой и приятной. Останется только две проблемы:
S>1. Быстрое двукратное нажатие на кнопку Send, что приводит к удваиванию запроса
S>2. Back после Send и Forward c "Retry". Что тоже приведет к удваиванию запроса.

S>Вторая проблема лечится редиректом после поста — 302. Редирект вызывает смену глагола на GET, а POST исчезает из history браузера.
S>Первую проблему лечат разными способами. Можно поискать в гугле по словам Post Exactly Once; можно просто в OnSubmit формы дизаблить кнопку Send.


как то ты сложно завернул. имхо паттерн PRG (POST REDIRECT GET или GET Afer POST ) попроще будет для понимания.

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

S>Начать, наверное, стоит с того, что viewstate — это зло. По тем же, в принципе, причинам — используя viewstate, вы отказыааетесь от адресуемости.
S>Впрочем, для сценария "редактирование бизнес-объекта" viewstate вполне подойдет, поскольку вряд ли кто-то захочет поставить букмарк "в середину" процесса редактирования.

S>Использовать для этого сессию — крайне плохое решение.
S>1. Что будет, если пользователь вышел покурить, а его сессия протухла? Теряем все сделанные изменения?
S>2. Что будет, когда вы удлините время жизни сессии, и одновременно в сессии будут лежать тысячи бизнес-объектов?
S>3. Что будет, когда один пользователь попытается поредактировать сразу два бизнес-объекта?

S>Viewstate масштабируется гораздо лучше.

Я не очень осознал набор утверждений "viewstate — это зло" и "Viewstate масштабируется гораздо лучше". Это не подколка, это вопрос — как их интерпертировать вместе?

В конкретно нашем случае:
Случай 1 — не проблема, а фича, наше приложение автоматом завершает сессию после периода неактивности (требования безопасности)
Случай 2 — удаляем бизнес-объект после того, как он отредактирован, это не спасет?
Случай 3 — согласен, здесь хоть что-то надо класть на страницу тем или иным способом (ключ объекта?)

Сценарий записи объекта в viewstate:
— объект сериализуется и пересылается (по медленному интернету) пользователю
— при загрузке страницы объект пересылается обратно на сервер (по медленному интернету) и десериализуется

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

Есть подозрение, что при большом размере объектов хранить их в сессии выгоднее, чем во viewstate. Или я что-то упускаю?

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




MG>Сценарий записи объекта в viewstate:
MG> — объект сериализуется и пересылается (по медленному интернету) пользователю
Так вы делаете интернет клиента еще более медленным
MG> — при загрузке страницы объект пересылается обратно на сервер (по медленному интернету) и десериализуется
И так тоже замедляете интернет то уже на пути к себе
Если есть БД то почему бы во вьюстейте не хранить уникальный ключ объекта в БД и потом при постбэке его поднимать
по ключу?
Зачем его запихивать во вьюстейт и если у вас нет
MG>Сценарий записи объекта в сессию:
MG> — сессия сохраняется на сервере сессии (в базе, в выделенном сервере сессии, так далее, эта часть системы нам подконтрольна), по быстрой внутренней сети. Скорее всего объект при этом тоже сериализуется
MG> — при загрузке страницы сессия зачитывается с сервера, опять же по быстрой внутренней сети, десериализация опять же происходит
с сервера ? если у вас сессия OutProc или в БД то по сути во втором случае в в своей БД храните 2 копии одних и тех же данных только в
разных форматах

MG>Есть подозрение, что при большом размере объектов хранить их в сессии выгоднее, чем во viewstate. Или я что-то упускаю?
Да есть глубочайшее подозрение что при хранении объектов в сессии а ЛУЧШЕ в БД горраздо эффективнее чем во вьюстейте.
Хотя как в том анекдоте whom how

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

MG>Я не очень осознал набор утверждений "viewstate — это зло" и "Viewstate масштабируется гораздо лучше". Это не подколка, это вопрос — как их интерпертировать вместе?
Сессия — самое большое зло.
Viewstate — зло поменьше.
Stateless page — это самый правильный способ работы. Не всегда этот идеал достижим.

MG>В конкретно нашем случае:
MG>Случай 1 — не проблема, а фича, наше приложение автоматом завершает сессию после периода неактивности (требования безопасности)
Ок, требования безопасности могут иногда привести к уменьшению удобства. Хотя применение viewstate позволяет, в принципе, сохранить изменения пользователя, даже выполнив требования безопасности — ему просто придется выполнить повторный логин.
MG>Случай 2 — удаляем бизнес-объект после того, как он отредактирован, это не спасет?
Я же говорю — одновременно. Проблема именно в этом: вот вы отдали страницу для редактирования бизнес объекта, написали на ней ключ к сессии, объект положили в сессию.
Всё, совершенно неизвестно, придет ли когда-то submit, или уже никогда. Объект лежит в сессии, пожирает ценные ресурсы. Пришел другой человек, открыл другой объект.

MG>Случай 3 — согласен, здесь хоть что-то надо класть на страницу тем или иным способом (ключ объекта?)
Проблема не в странице, а в том, что нужно оба объекта хранить в сессии. Наивный подход типа Session["currentObject"] = ... не сработает.
Далее, если человек неудачно навигируется, открывая на редактирование всё новые и новые объекты, его сессия будет "распухать". В HTTP нет способа надежно отловить закрытие страницы. Сессия — не кэш, удаление "старых" объектов не предусмотрено. Соответственно, нагрузка на сервер будет необоснованно расти.

MG>Есть подозрение, что при большом размере объектов хранить их в сессии выгоднее, чем во viewstate. Или я что-то упускаю?
Во-первых, Я не очень понимаю, каким именно образом вам удастся "поредактировать" большой объект на одной странице.
Можно как-то пояснить мне, какой набор элементов управления отдастся пользователю, чтобы объем изменяемых данных превысил 50 килобайт?
Или речь про редактирование изображений?

Во-вторых, в свете вышесказанного, большие объекты положат ваш сервер еще быстрее, чем мелкие.

Здравствуйте, 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 с большим количеством страниц. с каждым переходом информация накапливается, в конечной точке нужна информация по всем страничкам Визарда

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

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

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

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

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

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

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

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

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

Здравствуйте, 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 штук в месяц за программера и этим мало кто занимается, потому как не выгодно.

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

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


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

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

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

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

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

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

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

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

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

Я ваши остальные посты видел, выж вроде человек неглупый, но здесь я конкретно недоумеваю, что вас сподвигло нести такую феерическую чушь. Невосприятия связывания asp.net event модели чтоли? 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 + месяц на поддержку и кое-какую оптимизацию, а потом я иду в другую контору

Здравствуйте, C...R...a...S...H, Вы писали:

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

Я считаю, что вопросы поддержки вторичны по отношению к вопросам разработки стабильной и быстрой системы.

CRA>А в чем недовольство event based моделью? Можно услышать конкретные проблемы?

Синклер привел очень хороший пример — постбек на high-volume странице, приводить еще пару — просто лень печатать. Теоретически это просто попытка привести модель из WindowsForms в веб аппликейшн, и тут как и положительные аргументы так и отрицательные: все выглядит одинаково (это хорошо), но плохо ложится на низкоуровневые протоколы (это не очень хорошо). Внутри — windows forms базируются на message queue, а веб базируется на request-response схеме. Эвенты (как паттерн ленивого вызова) тут не самая красивая аналогия, но, как я уже говорил, — этот мир полон компромиссов.

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

— What is Gigashadow?
— Gigashadow is the end and it is the beginning.

MVC черезчур распространенное сочетание, и счас им называют все что угодно. Да, конечно, это паттерн отделения презентации от данных bla-bla-bla, но мне хочется сказать "хоть горшком назови, только в печку не суй".

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

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


BG>В общем, честно говоря, я не знаю "почему нельзя сделать сразу по уму". Народ почему то не делает.
Народ как правило применяет то, к чему приучен.
ASP.NET 1.0 был катастрофической вещью. Штука, которая по умолчанию делает максимально плохие решения, воспитала целое поколение людей с травмированным здравым смыслом.
К счастью, хотя бы 3.5 подает надежды на лучшее.
BG>Но меня это вполне устраивает: я могу прийти, посмотреть на проект, и сказать "за 6 месяцев мы это релизим, мне нужно a, b и с". И мы релизим за 5 + месяц на поддержку и кое-какую оптимизацию, а потом я иду в другую контору
"порулил — и убегай"?

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

BG>Здравствуйте, C...R...a...S...H, Вы писали:

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

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


CRA>>А в чем недовольство event based моделью? Можно услышать конкретные проблемы?

BG>Синклер привел очень хороший пример — постбек на high-volume странице, приводить еще пару — просто лень печатать. Теоретически это просто попытка привести модель из WindowsForms в веб аппликейшн, и тут как и положительные аргументы так и отрицательные: все выглядит одинаково (это хорошо), но плохо ложится на низкоуровневые протоколы (это не очень хорошо). Внутри — windows forms базируются на message queue, а веб базируется на request-response схеме. Эвенты (как паттерн ленивого вызова) тут не самая красивая аналогия, но, как я уже говорил, — этот мир полон компромиссов.
Поясните пожалуйста пример про постбек на high-volume странице.
Я не могу уловить суть проблемы.

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

BG>- What is Gigashadow?
BG>- Gigashadow is the end and it is the beginning.

BG>MVC черезчур распространенное сочетание, и счас им называют все что угодно. Да, конечно, это паттерн отделения презентации от данных bla-bla-bla, но мне хочется сказать "хоть горшком назови, только в печку не суй".
SOA тоже распространенное сочетание, и что?

Здравствуйте, C...R...a...S...H, Вы писали:

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

при нормальном применении defensive programming, логгинга и хорошем покрытии кода юнит тестами, поддержка сильно облегчается.

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

BG>>Синклер привел очень хороший пример — постбек на high-volume странице, приводить еще пару — просто лень печатать. Теоретически это просто попытка привести модель из WindowsForms в веб аппликейшн, и тут как и положительные аргументы так и отрицательные: все выглядит одинаково (это хорошо), но плохо ложится на низкоуровневые протоколы (это не очень хорошо). Внутри — windows forms базируются на message queue, а веб базируется на request-response схеме. Эвенты (как паттерн ленивого вызова) тут не самая красивая аналогия, но, как я уже говорил, — этот мир полон компромиссов.
CRA>Поясните пожалуйста пример про постбек на high-volume странице.
CRA>Я не могу уловить суть проблемы.

Лень писать одно и тоже. У вас страница с 1 000 000 уникальных клиенстких хитов в день, как вы ее будете делать: с Button_OnClick или же по формату http://myserver/mypage.aspx?ItemID={id}, второй формат будет побыстрее, т.к. не надо грузить родителя Button_OnClick, и юзеры могут ставить ссылки на страницу.

BG>>MVC черезчур распространенное сочетание, и счас им называют все что угодно. Да, конечно, это паттерн отделения презентации от данных bla-bla-bla, но мне хочется сказать "хоть горшком назови, только в печку не суй".
CRA> SOA тоже распространенное сочетание, и что?

Такое же бредовое.

Я когда в первый раз услышал словосочетание Software Factories мне тут же представилась большая полутемная комната с тысячью китайцев в кубиклах корпеющих над очередной реализацией Service Oriented Architecture. Я ужаснулся

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


BG>при нормальном применении defensive programming, логгинга и хорошем покрытии кода юнит тестами, поддержка сильно облегчается.

BG>Для больших систем... Возьмем, например, бизнес логику мобильного телекома с дневным прогоном бабла порядка 2 млн е через систему, разработка и тестинг (по времени в 2 раза большим чем собственно девелопмент) стоила очень много, тогда как поддержка стоила в разы меньше. Поверьте мне на слово, я там арком работал, и стабильность системы была одной из моих прямых обязанностей.
смотря что вкладывать в слово поддержка.
Вы видимо вкладываете в это слово такое поняние:
Система прошал CAT её установили на продакшен и посадили студента фиксить баги.
А я вкладываю в это доработку системы, добавление нового функианала, изменение бизнес правил и т.д.
А для системы в которой используется 2-3 подхода к архитектуре и code style, такие доработки многого стоят.
Хотя всегда есть вариант сказать: "шо за система, хто писал, срочно переписать..."


CRA>>Поясните пожалуйста пример про постбек на high-volume странице.
CRA>>Я не могу уловить суть проблемы.

BG>Лень писать одно и тоже. У вас страница с 1 000 000 уникальных клиенстких хитов в день, как вы ее будете делать: с Button_OnClick или же по формату http://myserver/mypage.aspx?ItemID={id}, второй формат будет побыстрее, т.к. не надо грузить родителя Button_OnClick, и юзеры могут ставить ссылки на страницу.
Мне кажется вы в данном примере бросаетесь в крайности.
Как сейчас помню ASP.NET одностраничные порталы...
С другой стороны:
Button_OnClick
{
redirect("")
}



BG>>>MVC черезчур распространенное сочетание, и счас им называют все что угодно. Да, конечно, это паттерн отделения презентации от данных bla-bla-bla, но мне хочется сказать "хоть горшком назови, только в печку не суй".
CRA>> SOA тоже распространенное сочетание, и что?

BG>Такое же бредовое.

BG>Я когда в первый раз услышал словосочетание Software Factories мне тут же представилась большая полутемная комната с тысячью китайцев в кубиклах корпеющих над очередной реализацией Service Oriented Architecture. Я ужаснулся
Боюсь даже спросить, выши мысли о Design pattens

Здравствуйте, C...R...a...S...H, Вы писали:

CRA>смотря что вкладывать в слово поддержка.
CRA>Вы видимо вкладываете в это слово такое поняние:

Я так и не понял, как из фразы о том, что "вопросы поддержки вторичны по отношению к вопросам разработки" вы вытянули это, ну да ладно.

CRA>Система прошал CAT её установили на продакшен и посадили студента фиксить баги.
CRA>А я вкладываю в это доработку системы, добавление нового функианала, изменение бизнес правил и т.д.
CRA>А для системы в которой используется 2-3 подхода к архитектуре и code style, такие доработки многого стоят. Хотя всегда есть вариант сказать: "шо за система, хто писал, срочно переписать..."

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

Да, блин, это все на самом деле, спор о сферических конях в вакууме. Т.е. суета и томление духа. Объясню:

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

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

CRA>Мне кажется вы в данном примере бросаетесь в крайности.
CRA>Как сейчас помню ASP.NET одностраничные порталы...

Мы с Синклером переломали уже добрую пару сотен копий, споря о целесообразности таких подходов. А после драки кулаками не машут.

CRA>Боюсь даже спросить, выши мысли о Design pattens

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

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

BG>Здравствуйте, C...R...a...S...H, Вы писали:

CRA>>смотря что вкладывать в слово поддержка.
CRA>>Вы видимо вкладываете в это слово такое поняние:

BG>Я так и не понял, как из фразы о том, что "вопросы поддержки вторичны по отношению к вопросам разработки" вы вытянули это, ну да ладно.
Я вывел это из вашего утверждения, что ваш опыт показывает, что процесс разработки системы дороже, чем процесс ее поддержки.
Если это не так, то извиняюсь


BG>Системы бывают разные, зеленые и красные. Различные архитектурные подходы, направленные на решение определенных задач, имеют приоритет по отношению к вопросам поддержки и развития системы.

BG>Да, блин, это все на самом деле, спор о сферических конях в вакууме. Т.е. суета и томление духа. Объясню:

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

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

Может быть вы и правы, но основным стимулом, сподвигшим меня на этот спор, было — узнать, что за контекст мог повлиять на решение использовать несколько архитектур в одном проекте.
Я еще не встречал проблем, решение которых требовало введение нескольких архитектур.

Здравствуйте, C...R...a...S...H, Вы писали:

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

Там немного по другому:
система разрабатывается релизами, поддержка идет параллельным процессом, но не привязана к релиз циклу: критические фиксы, баг фиксы и т.д. делаются малой кровью команды app support. У app support есть magic power идти сразу в систем тест и деплоить в течении недели. Все остальные сначала идут в integration test, потом в system test в течении 2 месяцев. Все большие изменения цепляются исключительно к релизу, иначе просто нельзя ввиду большого regression test.

В app support систему сторожит набор слабых инженеров — их задача только в том что бы зафиксировать проблему, быстро что-то починить, и передать это аркам. Арки оценивают стоимость фикса и если фикс короткий, он отправляется в маленькую команду app support dev — очень сильные и ответственные инженеры, прекрасно знающие систему. Если фикс длинный он отдается команде, которая отвечает за этот или близкий модуль в данном релизе.

Так же у арков есть обязанность проверки архитектуры релизов на совместимость с продакшеном.

Это во взрослых конторах.

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

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

С точки зрения сферического софта в вакууме такие подходы очень плохие, конечно, но жизнь вносит свои коррективы.

CRA>Может быть вы и правы, но основным стимулом, сподвигшим меня на этот спор, было — узнать, что за контекст мог повлиять на решение использовать несколько архитектур в одном проекте.
CRA>Я еще не встречал проблем, решение которых требовало введение нескольких архитектур.

Вам повезло У меня они каждый день

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

BG>Здравствуйте, C...R...a...S...H, Вы писали:

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

BG>Там немного по другому:
BG>система разрабатывается релизами, поддержка идет параллельным процессом, но не привязана к релиз циклу: критические фиксы, баг фиксы и т.д. делаются малой кровью команды app support. У app support есть magic power идти сразу в систем тест и деплоить в течении недели. Все остальные сначала идут в integration test, потом в system test в течении 2 месяцев. Все большие изменения цепляются исключительно к релизу, иначе просто нельзя ввиду большого regression test.

BG>В app support систему сторожит набор слабых инженеров — их задача только в том что бы зафиксировать проблему, быстро что-то починить, и передать это аркам. Арки оценивают стоимость фикса и если фикс короткий, он отправляется в маленькую команду app support dev — очень сильные и ответственные инженеры, прекрасно знающие систему. Если фикс длинный он отдается команде, которая отвечает за этот или близкий модуль в данном релизе.

BG>Так же у арков есть обязанность проверки архитектуры релизов на совместимость с продакшеном.

BG>Это во взрослых конторах.
Так вот я получается что поддержка обходится дороже чем создание системы.
А если система еще написана через одно место, то вообще исправление дефекта в одном месте убивает систему в другом.
Хочу заметить одно:
Все что вы написали ни коим образом не сходится с тем что вы писали ранее (сделали систему, установили, и побежали дальше...)
Сейчас по вашим словал систему поддерживают не просто пара программеров, а:
*Пара программеров
*Арки
*Апп сапортеры
Предположу, что этим хозяйством еще ПМ рулит.

Так тогда, что вы говорили по поводу того, что разработка дороже поддержки?



BG>В детском саду все по другому: проджект тим, тестер и дба если повезет. Система релизов по фазам (часто между фазами проджект тим меняется), в поддержку отправляется самый слабый член команды, потому как за время проекта инженеры устают как от проекта, так и от клиента. Всем хочется новизны, и народ используют весь свой вес (кто во что горазд), что бы перескочить на другой проект, и проекты с нуля тут ценятся больше всего. У джуниора веса как правило нет, и он остается на поддержке
Интересно, но есть одна проблема, которая отличает два представленных способа вести проект:
При первом способе во вселенной существуют сильные программеры которым нравиться сапорт (мне кажется это фантастика )
А вот во втором случае таких программеров не существует.




BG>Сами понимаете, что в любом из вариантов вопросы поддержки вторичны Полезное качество для хорошего тимлида — уметь узнавать такие ситуации и знать как с ними бороться. Если при этом он еще сможет сохранить команду, то ему всеобщий почет и уважение.
Так вот и получается что своими решениями добавить парачку архитектурных решения в один проект, вы закапываете всю каманду, потому что проект превращается, превращается проект в жуткого монстра, который содержит в себе несколько архитектурных решений аля:
Половина объектов домена использует Lazy load, а другая половине нет.
И народ, который сам же и писал эту систему уже не в силах что то поменять, и поэтому уходит в другие проекты.



BG>С точки зрения сферического софта в вакууме такие подходы очень плохие, конечно, но жизнь вносит свои коррективы.

CRA>>Может быть вы и правы, но основным стимулом, сподвигшим меня на этот спор, было — узнать, что за контекст мог повлиять на решение использовать несколько архитектур в одном проекте.
CRA>>Я еще не встречал проблем, решение которых требовало введение нескольких архитектур.

BG>Вам повезло У меня они каждый день
ООООО...
Отлично!!!
Я затеял этот спор только для того, что бы узнать хоть парачку таких проблем.
Поделитесь пожалуйста.

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

BG>Здравствуйте, C...R...a...S...H, Вы писали:

CRA>>Так тогда, что вы говорили по поводу того, что разработка дороже поддержки?

BG>потому что я не упомянул еще 10-20 релиз проджект тимов в каждой в среднем по 10 — 15 человек, которые занимаются собственно разработкой функциональности релиза. Затраты на саппорт на фоне затрат на проджект команды и тест команды в релизе, ничтожны.
ОК.

BG>Что до разных методов, то я работал в разных компаниях и смотрел по сторонам. Во взрослых конторах стабильность и качество системы как правило имеет приоритет. В детских садах, приоритет имеют сроки. То, что я называю Customer Driven Testing, т.е. мы фиксим только те баги, которые находит кастомер. Это не смешно, конечно же, но тем не менее — реальность.
Интересное замечание.


CRA>>При первом способе во вселенной существуют сильные программеры которым нравиться сапорт (мне кажется это фантастика ) А вот во втором случае таких программеров не существует.

BG>Никто не говорил, что им нравится саппорт У них другие бенефиты.


CRA>>Так вот и получается что своими решениями добавить парачку архитектурных решения в один проект, вы закапываете всю каманду, потому что проект превращается, превращается проект в жуткого монстра, который содержит в себе несколько архитектурных решений аля:
CRA>>Половина объектов домена использует Lazy load, а другая половине нет.
CRA>>И народ, который сам же и писал эту систему уже не в силах что то поменять, и поэтому уходит в другие проекты.

BG>Я не считаю это большим грехом. Статические данные вплоне могут грузиться как и ленивым способом так и "все сразу". Конечно, было бы хорошо, если бы грузились одинаковым, но на некотором этапе развития системы это уже не возможно. Называется organic growth.
Да ладно, это называется кривая арзитектура.
Это как создавать машину и на середине сборки использовать вместо стали дерево, и говорить что мол так дешевле

CRA>>Отлично!!!
CRA>>Я затеял этот спор только для того, что бы узнать хоть парачку таких проблем.
CRA>>Поделитесь пожалуйста.

BG>Я подписываю NDA, который в частности запрещает мне обсуждать детали архитектуры. А проблемы когда текущая архитектура сильно усложняет процесс, кроются как раз в этих самых деталях.

BG>Хотя ладно: имеем модную архитектуру с nettiers orm, enterprise library, infragistics controls. Административный запрет на прямой доступ к базе. Во время первого бета релиза клиенту выясняется, что
BG>1) при 5000+ записей в основных словарях (девелоперы использовали не больше трех записей типа Клиенты, Юзера, Продукты), все списки начинают тормозить, отжирая порядка 700 метров после 5 кликов на юае, да и грузяться порядка 100 секунд.
Думаю что это — _реальный_ дефект архитектуры системы.
Странно, если ваш архитектор до сих пор, не знал что HTML, не особо предназначен для вывода 5000+ элементов пользователю.
К тому же вы хоть и писали про правильный процесс разработки, видимо даже не удосужились провести нагрузочное тестирование

BG>2) при загрузке реальных продуктов (там 4 поля типа текст, полный вес объекта может превышать 8 метров) выяснилось, что на клиента отправляется порядка 10 мегабайт viewState, потому что кто-то очень умный сохраняет этот объект во вью стейт.
Ничего не понятно, что за объект такой.

BG>Решения:
BG>1)
BG>* профайлером было обнаружено, что infragistics очень любит GetHashCode() метод, который оверлоадиться в энтитях в формате:
BG>GetHashCode() { return property1.ToString + property2.ToString + ... }
BG>Поменяли.
Странно я всегда думал что возвращаемое значение у GetHashCode() Int32


BG>* Для генерации списков nettiers генерит специальные классы типа WebControls, нечитабельные совершенно, к тому же не поддерживающие ничего кроме IEnumerable()
BG>После долгих споров я всех убедил это переписать на ObjectDataSource с прямым ad hoc сиквелом стало серьезно быстрее и память больше не текла. Тут можно было бы сделать еще быстрее, но юай использовал Infragistics контроли с очень богатой написанной функциональностью, переписывать которую вручную времени не было.
Интересно кончено, но по тому что вы написали я ничего не могу сказать конкретного, так как мне лично ничеге не понятно, с nettiers так что умываю руки

BG>2) Хакнули через сохранение ViewState на сервере. Это чревато, конечно, но опять же — не было времени.
Вот вот, а вы говорили что — "В детских садах, приоритет имеют сроки"

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

BG>Как вы и сами понимаете ни я ни мой коллега этот проект видеть больше не хотели
Так получается у вас как в детском саду?

Здравствуйте, C...R...a...S...H, Вы писали:

BG>>2) при загрузке реальных продуктов (там 4 поля типа текст, полный вес объекта может превышать 8 метров) выяснилось, что на клиента отправляется порядка 10 мегабайт viewState, потому что кто-то очень умный сохраняет этот объект во вью стейт.
CRA>Ничего не понятно, что за объект такой.

обычный Продукт с четырьмя текстовыми описаниями, и прочей лабудой. Беда была в форме его редактирования — InfragisticsTabControl с пятью табами, каждый делал что то интересное. Разработчик решил, что самым лучшим способом передавать продукт между табами, будет ViewState. Это, конечно, работало на ура, т.к. девелоперы не заполняли текстовые поля продукта поэтому вес сериализованного продукта был меньше килобайта, и ни кого не волновал. Как только запихали реальные продукты с реальными описаниями, вес сериализованного Продукта увеличился до 8 метров, и стало немного тяжеловато. Опять же проблема прояснилась когда я из дома на это смотрел — на работе толстый канал чуть ли не 2 мега аплоад, там чуток подтормаживало но не сильно, а вот из дома с моими 384Килобитами, 8 метров аплоада на постбаке было уже существенно.

Проблема была еще в том, что начальные разработчики не придерживались философии: глупый юай, умный бакэнд, поэтому большая часть бизнес логики была запихана прямо в aspx страницы, не самым оптимальным способом. Рефакторить этот код было очень тяжело и в некоторых случаях практически не возможно. На полную перепись формы редактирования ушло бы недели три (спеков нет, тестов нет, нихрена нет), а времени уже практически не оставалось.

BG>>Решения:
BG>>1)
BG>>* профайлером было обнаружено, что infragistics очень любит GetHashCode() метод, который оверлоадиться в энтитях в формате:
BG>>GetHashCode() { return property1.ToString + property2.ToString + ... }
BG>>Поменяли.
CRA>Странно я всегда думал что возвращаемое значение у GetHashCode() Int32

ну значит таким образом
GetHashCode() {return property1.ToString().GetHashCode() + property2.ToString().GetHashCode() ... }
я уже честно сказать не помню, дело было в сентябре Суть в том, что GetHashCode для ентитей считался как суммарный нашкод всех мемберов (а те в свою очередь тоже могли быть сложными объектами). ToString() там точно был, потому что именно по ToString() я его и нашел в профайлере: у нас 5000 продуктов в базе, на гриде отображается страница в 20 продуктов, а при этом у меня в профайлере 3 000 000 вызовов ToString(). понятное дело WTF?! Переделали, что бы возвращал EntityID, т.к. и продукты и юзера и клиенты имеют primary key, который в общем то и определяет их идентичность.

CRA>Интересно кончено, но по тому что вы написали я ничего не могу сказать конкретного, так как мне лично ничеге не понятно, с nettiers так что умываю руки

Я надеялся, что вам будет понятно, что неттиерс использовать не стоит

BG>>Как вы и сами понимаете ни я ни мой коллега этот проект видеть больше не хотели
CRA>Так получается у вас как в детском саду?

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

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

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

Кстати, я так не считаю. Контролов под него нет, хотя сама по себе реализация MVC сделана неплохо, ее даже можно без труда превратить в MVP. В данном виде этот фреймворк хорош для internet — приложений с простым интерфейсом.

Если же брать корпоративынй интранет, то даже мой самописный MVP-фреймворк делает работу более удобной, чем то, что сейчас есть у MS.