Здравствуйте, adontz, Вы писали:
A>Описанная ситуация не может быть штатной, так как нарушена целостность данных Хотя, если для тебя нарушенная целостность данных штатная ситуация...
Ты неверно понимаешь термин целостность данных.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>А какие у тебя проблемы с кешированием? Ты его затолкал в DAL только потому что так удобнее и теперь считаешь его неотъемлемой частью DAL?
Да нет, дело не в том что удобнее, а в том что правильнее. Кеш должен быть прозрачным для пользователя, не должно быть нескольких хранилищ.
Здравствуйте, gandjustas, Вы писали:
G>Или тот же пример с городами: запросили сначала список городов с количеством кастомеров, потом запрашиваем катомеров из конкретного города. Между запросами другой пользователь поменял одному из кастомеров в город. Какая ссылочная структура поможет отследить изменение количества в двух городах?
В данном примере всё очень просто, надо считать агрегаты на клиенте, только на основе имеющихся у него данных. Тогда данные будут всегда целостными, хотя, возмодно, и устаревшими немного.
Здравствуйте, adontz, Вы писали:
IT>>А какие у тебя проблемы с кешированием? Ты его затолкал в DAL только потому что так удобнее и теперь считаешь его неотъемлемой частью DAL?
A>Да нет, дело не в том что удобнее, а в том что правильнее. Кеш должен быть прозрачным для пользователя, не должно быть нескольких хранилищ.
Правильнее понятие недетерминированное. Например, ты искренне заблуждаясь считаешь, что понятие integrity применимо к выборки данных и это правильно.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Или тот же пример с городами: запросили сначала список городов с количеством кастомеров, потом запрашиваем катомеров из конкретного города. Между запросами другой пользователь поменял одному из кастомеров в город. Какая ссылочная структура поможет отследить изменение количества в двух городах?
A>В данном примере всё очень просто, надо считать агрегаты на клиенте, только на основе имеющихся у него данных. Тогда данные будут всегда целостными, хотя, возмодно, и устаревшими немного.
Только для этого надо запрашивать список всех кастомеров каждый раз.
Вообще это получается решение соотвествующее жирной модели, которое тяготеет к вытягиванию всей базы на клиента.
Потом идет придумывание LazyLoad, кеширования и прочих гадостей.
Здравствуйте, gandjustas, Вы писали:
A>>В данном примере всё очень просто, надо считать агрегаты на клиенте, только на основе имеющихся у него данных. Тогда данные будут всегда целостными, хотя, возмодно, и устаревшими немного. G>Только для этого надо запрашивать список всех кастомеров каждый раз.
Как показала практика, нет. Во-первых, не каждый раз, а всего один раз и время от времени обновлять. Во-вторых, не всех, а только видимых данному оператору. Права доступа на уровне DAL — великая вещь.
G>Вообще это получается решение соотвествующее жирной модели, которое тяготеет к вытягиванию всей базы на клиента. G>Потом идет придумывание LazyLoad, кеширования и прочих гадостей.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>В данном примере всё очень просто, надо считать агрегаты на клиенте, только на основе имеющихся у него данных. Тогда данные будут всегда целостными, хотя, возмодно, и устаревшими немного. G>>Только для этого надо запрашивать список всех кастомеров каждый раз.
A>Как показала практика, нет.
Если ты еще не нарвался на проблему, то это не значит что её не существует.
A>Во-первых, не каждый раз, а всего один раз и время от времени обновлять.
Тогда можно время от времени перезапрашивать выборку городов с количеством клиентов, а список клиентов получать только нужный. Это будет рабоать гораздо быстрее чем синхронизация кешей.
В твоем случае с расчетом на клиенте придется обновлять весь список клиентов.
Работать все будет быстрее.
A>Во-вторых, не всех, а только видимых данному оператору.
Это не зависит от технологии доступа к БД.
A>Права доступа на уровне DAL — великая вещь.
У тебя фильтрация по уровню доступа в DAL?
Это ужасно.
G>>Вообще это получается решение соотвествующее жирной модели, которое тяготеет к вытягиванию всей базы на клиента. G>>Потом идет придумывание LazyLoad, кеширования и прочих гадостей. A>Ты просто не умеешь их готовить.
Я-то как раз умею, поэтому и не использую.
G>Кроме того в нормальном DAL не будет GetById, FindByFirstName, будет ExecuteQuery(QueryObject).
А почему не будет? Или скажем почему GetById не могут из себя вызывать ExecuteQuery(QueryObject)? Религия?
Здравствуйте, Tom, Вы писали:
G>>Кроме того в нормальном DAL не будет GetById, FindByFirstName, будет ExecuteQuery(QueryObject). Tom>А почему не будет? Или скажем почему GetById не могут из себя вызывать ExecuteQuery(QueryObject)? Религия?
Могут, только это будет не DAL.
При таком походе getById — это будет метод, который возвращает QueryObject c нужной выборкой. Это будет вспомогательный метод для BL.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>Права доступа на уровне DAL — великая вещь. G>>У тебя фильтрация по уровню доступа в DAL? G>>Это ужасно.
A>Это замечательно, потому что в фильтрации нет бизнес-логики.
Это и есть бизнес-логика.
Здравствуйте, Tom, Вы писали:
A>>QueryObject нужен для нетипичных запросов, типа запросов для отчётов. Использовать его для всего подряд просто неправильно. Tom>Тут соглашусь с Ромой
С чем соглашиься? С голословным утверждением?
Может тогда ты ответишь почему это "просто неправильно" ?
Здравствуйте, gandjustas, Вы писали:
A>>>>Права доступа на уровне DAL — великая вещь. G>>>У тебя фильтрация по уровню доступа в DAL? G>>>Это ужасно. A>>Это замечательно, потому что в фильтрации нет бизнес-логики. G> G>Это и есть бизнес-логика.
Здравствуйте, adontz, Вы писали:
G>>Вообще это получается решение соотвествующее жирной модели, которое тяготеет к вытягиванию всей базы на клиента. G>>Потом идет придумывание LazyLoad, кеширования и прочих гадостей.
A>Ты просто не умеешь их готовить.
Рома, не изобретай велосипед, возми лучше сразу NHibernate или EF и не парься. Там все эти какашки парни уже давно за тебя придумали.
Если нам не помогут, то мы тоже никого не пощадим.
VD>SOA — это драцкий базворд за которым нет ничего нового. К компонентам (кстати "компонентов", а не "компонента") SOA не имеет никакого отношения. Расшифровывается этот базворд как "архитектура ориентированная на сервисы". Это тоже самое что серверы ориентированные на RPC. Дурацкий базвордов придумать можно миллионы (что и делаеют конторы вроде МС каждый день), но толку от этого не будет, так как ничего принципиально нового от этот не появится. VD>SOA родилась в момент когда в МС полностью отчаялись протащить DCOM в область разработки серверов приложений. Тогда они понял, что общаться с серверами намного проще по средствам RPC (без сохранения состояния между вызовами на сервере). Тогда срочно придумали веб-сервисы, а чтобы все это круто звучало и никто не догадался, что это просто откат к более "примитивной" технологии и признание недееспособности ООП в области организации распределенных вычислений назвали все это SOA. Как и любой базворд это звучит красиво, не понятно. Что еще нужно чтобы завуалировать собственную глупость?
Хотя, если для тебя нарушенная целостность данных штатная ситуация...
Если нам не помогут, то мы тоже никого не пощадим.
