Здравствуйте, 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.
То что БО должен заполняться полностью я понимаю, хотя считаю что ето не оптимально. Например при заполнении грида из сложных запросах где используют много таблиц.
У нас на работе я пытаюсь приблизить работу с БО, но у меня самого нет ответа на вопрос почему надо заполнять всеми полями коллекцию с кучей объектов, если DataReader или DataTable позволяет передать только самое необходимое.
Может ето детская болезнь при переходе на работу с БО.
У меня есть ещё вопросы по БО и их разновидности, но хочу ето поднять в однельном топике
