Здравствуйте, Alex Getman, Вы писали:
AG>спасибо за подробный ответ.
P>>Приведенный кусок кода очень напоминает паттерн Singleton. Если каждый объект в Вашем приложении является
P>>"глобальным", возможно необходимо пересмотреть архитектуру.
AG>Объект является глобальным в смысле сессии Юзера. Тоесть каждый пользователь работает с выбранным Orgunit, Report, а хранилищем для объекта (между вызовами страниц) является HTTP Session, так как сессия уникальна, объекты юзеров не пересекаются.
P>>Пользователь может сменить компьютер и все бизнесс объекты будут пересозданы заново, хотя пользователь возможно ожидал "предыдущего" поведения.
AG>вот здесь я не понял. если юзер сменил компьютер — он должен залогинится в систему, его сессия создается заново, объекты инициализируются и т.д.
P>>Сессия "плохо" масштабируется. Чтобы достичь масштабируемости необходимо либо заставить пользователя носить с собой все объеты, что осерьезно увеличивает трафик, либо выделять под хранение сессии отдельный сервер.
P>>Если постоянно не сохраняют свое состояние в перманентное хранилище (база данных, напиример), то в случае сбоя возможна потеря данных (что часто бывает неприемлимо).
P>>Использование внутри самого объекта логики кэширования приводит к тому, что при необходимости изменить политику кэширования Вам придется переписать все объекты. Это должен делать "кто-то" один. Посмотрите в сторону паттерна Repository (Martin Fowler).
P>>Применение ASP.NET специфичной средств (HTTP session) приводит к тому, что Ваши объекты не могут быт ьснова использоаны, скажем, в декстоп приложениях. В целом бизнесс объекты не должны обладать такими знанями как сессия.
P>>[/list]
AG>с перечисленным согласен.
P>>То есть после того, как Вы закончили работать с объектом сохраните его в базу данных и при соледующем HTTP запросе поднимите его из базы и снова работайте с ним. Потому что сервер базы данных очень просто масштабировать в случае, когда база данных станет "узким местом" Вашей системы.
AG>тут не согласен. по-моему опыту лучше 10 метров в памяти чем одно обращение к базе, база может находится на физически другом сервере, что повлечет большие расходы на траффик + безопасность.
Это решение не масштабируется. Оно может работать только в пределах одного сервера.
AG>Ок, я возможно не совсем понятно описал в первом посте, попробую сказать чего хотелось бы добится на данном этапе:
AG>1. Например, есть aspx страничка, для ввода приказа. Пользователь заходит на нее, вводит данные и нажимает Submit. Данные нужно проверять, информировать Юзера об ошибках и сохранять при повторном Submit.
При работе с базой данных все происходит точно в таком порядке — сначала валидация данных, вывод сообщений об ошибке, после корректировки данных создание объекта и запись его в базу.
AG>2. Существует несколько сущностей, которые создаются на протяжении нескольких итераций Юзера с разными страницами aspx (что-то вроде визарда) Опять же, не хочется вставлять в код непосредственно странички вызовы OracleCommand и постоянно дергать базу.
Промежуточные объекты вполне могут жить или в сессии, или во вьюстейте, или в базе.
AG>3. Для обеспечения всей этой функциональности хочется построить красивую объктную модель на стороне C# — в коде Page будет только вызовы меотдов класса Order:
Объектная модель никак не зависит от способа хранения экземпляров классов, ее составляющих.
// Submit click
// Перед изменением объект загружается из базы данных.
string orderId = this.Request.Params["OrderId"];
Order myOrder = Order.Load(orderId);
// Изменяется
myOrder.Date = DateTimeTextBox.Value;
if (!myOrder.Valid())
return;
// Сохраняется
myOrder.Save();
AG>проблема в том, как наиболее эфективно сохранять объекты между вызовами ASP.NET странички?
Оперативная память — это временной хранилище. Наиболее надежным и правильным вариантом будет хранить данные в базе данных.
AG>p.s. если я что-то не совсем ясно описал, please feel free to ask about details 
Боишься — не делай, делаешь — не бойся.
