Здравствуйте, Alex Getman, Вы писали:
AG>Hi all.
Доброго времени суток.
AG>Интересует следующий вопрос — есть информационная система с Web интерфейсом, написанная на ASP.NET 1.1, в данный момент архитектура разеделна на слои классов/объктов которые отвечают за бизнесс-логику, доступ к данным etc.
Разделение на слои есть правильно безусловно.
AG>Взаимодейтсвие объктов обеспечивается следующим образом — для текущей сессии Юзера создаются экземпляры сущностей (Orgunit, Employee, Report etc.) которые используют сессию для хранения своего состояния, тоесть каждый объект реализует что-то вроде:
AG>AG>public class SalaryDetailReport
AG>{
AG> private static readonly string sessionId = "OrganizationHierarchy.Payroll.Reports.SalaryDetailReport";
AG> public static SalaryDetailReport Current
AG> {
AG> get
AG> {
AG> if (HttpContext.Current.Session[SalaryDetailReport.sessionId] != null)
AG> {
AG> SalaryDetailReport report = (SalaryDetailReport)HttpContext.Current.Session[SalaryDetailReport.sessionId];
AG> return report;
AG> }
AG> else
AG> {
AG> SalaryDetailReport report = new SalaryDetailReport();
AG> HttpContext.Current.Session[SalaryDetailReport.sessionId] = report;
AG> return report;
AG> }
AG> }
AG> set
AG> {
AG> HttpContext.Current.Session[SalaryDetailReport.sessionId] = value;
AG> }
AG>}
AG>
Приведенный кусок кода очень напоминает паттерн Singleton. Если каждый объект в Вашем приложении является "глобальным", возможно необходимо пересмотреть архитектуру.
AG>Вообщем-то сейчас работает нормально, но меня интересует насколько "правильным" можно назвать такой подход к организации взаимодействия бизнесс-объектов?
К сожалению не могу назвать этот подход правильным. Вот несколько причин (не вдаваясь в подробности работы бизнесс объектов):
Пользователь может сменить компьютер и все бизнесс объекты будут пересозданы заново, хотя пользователь возможно ожидал "предыдущего" поведения.
Сессия "плохо" масштабируется. Чтобы достичь масштабируемости необходимо либо заставить пользователя носить с собой все объеты, что осерьезно увеличивает трафик, либо выделять под хранение сессии отдельный сервер.
Если постоянно не сохраняют свое состояние в перманентное хранилище (база данных, напиример), то в случае сбоя возможна потеря данных (что часто бывает неприемлимо).
Если сессия используется в качестве кэша объектов, опять же возможна работа пользователя с устаревшими данными. Вопрос кэширования обсуждается здесьАвтор: снежок
Дата: 14.06.06
и здесьАвтор: Joker6413
Дата: 16.06.06
. В целом даже кэширование следует применять в пределах одного запроса.
Использование внутри самого объекта логики кэширования приводит к тому, что при необходимости изменить политику кэширования Вам придется переписать все объекты. Это должен делать "кто-то" один. Посмотрите в сторону паттерна Repository (Martin Fowler).
Применение ASP.NET специфичной средств (HTTP session) приводит к тому, что Ваши объекты не могут быт ьснова использоаны, скажем, в декстоп приложениях. В целом бизнесс объекты не должны обладать такими знанями как сессия.
AG>Может быть у кого-то есть опыт альтернативных решений? Имеет ли смыл особо критичные части для призводительности системы переписать для того, чтобы обеспечить сохранение объектов в Cache по ключу уникальному для каждой сессии пользователя?
Возможно более правильным решением будет работать с объектами в пределах обработки одного запроса к серверу и дальше "отпускать" их. Представьте ситуацию в которой есть следующий объект:
public class EmployeeYearReport
{
public int[] Data
{
get
{
// Тут возвращается масссив с миллионами записей
}
}
}
Тогда кэширование таких объектов приведет к исключетельно нерациональному расходованию ресурсов (память сервера, сетевой канал и т.д.). Кэш распухент и будет мешать "ходить".
То есть после того, как Вы закончили работать с объектом сохраните его в базу данных и при соледующем HTTP запросе поднимите его из базы и снова работайте с ним. Потому что сервер базы данных очень просто масштабировать в случае, когда база данных станет "узким местом" Вашей системы.
Боишься — не делай, делаешь — не бойся.
