Re[7]: [Domain model] - кол-во обращений к БД при загрузке с
От: GlebZ Россия  
Дата: 02.10.05 11:17
Оценка:
Здравствуйте, IDL, Вы писали:

IDL>Я не совсем понял, как ты поступаешь или советуешь поступать в таких ситуациях.

Вариант a) Делать различные методы которые загружают ту, или иную конфигурацию объектов. Самый простой вариант, но и самый жесткий. При изменении бизнес-объектов, придется переписывать и весь ворох запросов.
Вариант b) Жестко прописать типы с избыточностью загрузки. Более гибкий способ, поскольку запрос обычно строится на основе метаданных объектов.
Вариант с) Язык запросов который трансформируется в пакет SQL запросов. Самый гибкий, но и самый сложный вариант. Если есть жесткое отношение таблица-тип(или функция-тип), то строится достаточно легко. Значительно усложняется если есть другие отношения между ООП бизнес-объекта и схемой данных. При введении наследования, все значительно усложняется.

С уважением, Gleb.
Re[8]: [Domain model] - кол-во обращений к БД при загрузке с
От: IDL  
Дата: 04.10.05 08:10
Оценка:
Здравствуйте, GlebZ, Вы писали:

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


IDL>>Я не совсем понял, как ты поступаешь или советуешь поступать в таких ситуациях.

GZ>Вариант a) Делать различные методы которые загружают ту, или иную конфигурацию объектов. Самый простой вариант, но и самый жесткий. При изменении бизнес-объектов, придется переписывать и весь ворох запросов.

Разная конфигурация объэктов подразумевает частичное заполнение данными объекта.
А как следить с какой конфигурацией ты работаешь.


GZ>Вариант b) Жестко прописать типы с избыточностью загрузки. Более гибкий способ, поскольку запрос обычно строится на основе метаданных объектов.



Не совсем понял, что ты имеешь ввиду

GZ>Вариант с) Язык запросов который трансформируется в пакет SQL запросов. Самый гибкий, но и самый сложный вариант. Если есть жесткое отношение таблица-тип(или функция-тип), то строится достаточно легко. Значительно усложняется если есть другие отношения между ООП бизнес-объекта и схемой данных. При введении наследования, все значительно усложняется.


Ты пишешь про способ составления запросов, но не заполнения объектов разной порцией данных. В принципе етот способ самый гибкий для заполнения объектов не полной информацией.


В принципе мой вопрос про то, где золотая середина, между тем заполнять ли объект всегда всеми данными или только необходимыми для даной транзакции.
В идее частичном запонении объекта кроются сюрпризы, ибо можно использовать какую-то функцию и даже не подозревать, что она работает не корректно, по причине не полной загрузки объекта данными.
Re[9]: [Domain model] - кол-во обращений к БД при загрузке с
От: GlebZ Россия  
Дата: 04.10.05 09:32
Оценка: 2 (1)
Здравствуйте, IDL, Вы писали:

IDL>Разная конфигурация объэктов подразумевает частичное заполнение данными объекта.

IDL>А как следить с какой конфигурацией ты работаешь.
Ни в коем случае. Каждый объект либо загружен, либо его нет. В полузагруженном объекте больше вреда чем радости. В данном контексте можно говорить только о загрузке графа связанных объектов.

GZ>>Вариант b) Жестко прописать типы с избыточностью загрузки. Более гибкий способ, поскольку запрос обычно строится на основе метаданных объектов.

IDL>Не совсем понял, что ты имеешь ввиду
То что перед этим описывал. Метаданными определяем границы объекта, он полностью(и только полностью) загружается.

IDL>Ты пишешь про способ составления запросов, но не заполнения объектов разной порцией данных. В принципе етот способ самый гибкий для заполнения объектов не полной информацией.


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

IDL>В идее частичном запонении объекта кроются сюрпризы, ибо можно использовать какую-то функцию и даже не подозревать, что она работает не корректно, по причине не полной загрузки объекта данными.
Нет, экземпляр объекта обязан быть полным. Частично заполненный объект противоречит основе архитектуры ООП. А именно, сильной привязке к внутренним данным. Исключение можно делать только для BLOB, с помощью ленивой инициализацией. Если ты отвязываешься от части данных, то лучше это выделить в отдельный объект, и выделить в отдельную сущность на РСУБД. Потому как, ты также избыточно нагружаешь запросы(и кэш БД) лишними данными.
Есть один метод помещения разных типов на одну сущность РСУБД для увеличении эффективности загрузки данных. Основан на наследовании. Ну например, описываем классы:
class CA
{
int pk;
int a;
...
}
final class CB:CA
{
int b;
....
}
final class CC:CA
{
int c;
.....
}

Для того, чтобы убрать избыточность и сложность запросов и сделать их более эффективными, определяем таблицу:
CREATE TABLE MMM
(
pk int primary key,
type varchar(30) NOT NULL,
a int NOT NULL,
b int NULL,
c int NULL
)

В результате в данной таблице могут храниться три типа — CA, CB, CC. И если нам нужны все объекты наследованные от типа CA, то это выливается в один быстрый запрос:
select pk, type, a, b, c from MMM

При заполнении проверяем тип объекта(поле type), и создаем именно нужный тип объекта.
Если нужен например только тип CB, то запрос будет ненамного сложней
select pk, a, b from MMM where type='CB'

Все ненужные поля для данного типа объекта в реляционке заполняются NULL значениями. Тогда для основных данных он их и не хранит.
Этот способ не противоречит принципам OOP.

С уважением, Gleb.
Re[10]: [Domain model] - кол-во обращений к БД при загрузке
От: IDL  
Дата: 04.10.05 12:40
Оценка:
То что БО должен заполняться полностью я понимаю, хотя считаю что ето не оптимально. Например при заполнении грида из сложных запросах где используют много таблиц.

У нас на работе я пытаюсь приблизить работу с БО, но у меня самого нет ответа на вопрос почему надо заполнять всеми полями коллекцию с кучей объектов, если DataReader или DataTable позволяет передать только самое необходимое.

Может ето детская болезнь при переходе на работу с БО.

У меня есть ещё вопросы по БО и их разновидности, но хочу ето поднять в однельном топике
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.