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

B>>Проблем с отладкой проксей не ещё возникало.
IB>Наверное потому что ты используешь гибернейт по стандартному сценарю..
Не только. Имел опыт с написанием и использованием проксей в других решениях.

B>>На клиенте не нужны прокси.
IB>А если нужны? Или, повторюсь, структура объекта другая?
Такая же структура.

IB>А что делать если часть дерева ненужна? Придумывать дополнительные DTO или предавать не доконца инициализированные объекты?
IB>И за что боролись?
Нет, на этапе сериализации решается что нужно клиенту а что нет. Например через WSDL. Клиент получает только то что описано в WSDL. Но в той же структуре данных без проксей. То что ему не нужно в этой структуре null.

B>>Нееее. Стоп. Репозиторий это не абстрактный DAO.
IB>Почему нет?
DAO — класс доступа к данным. На репозиторий же мы накладываем функциональность — держать объекты которые уже прочитаны, но таскать их мы с собой не можем, так как у объектов модели нет ссылок.

B>> Нам нужно где-то держать сущности, которые мы заранее вычитали (перфоманс тюнили) но они нам не везде нужны, чтобы их таскать по всему коду.
IB>И чем DAO для этого не годится? Это же тупо персистентный контейнер, логику кеширования вполне можно возложить и на него, как минимум в первом приближении, если не ожидается каких-то уж совсем противоестественных телодвижений.
Мне не нужен класс доступа к данным, мне нужен класс для связывания объектов модели. Размазывать DAO по всем слоям гораздо хуже чем проделывать тоже самое с репозиторием. DAO сильно завязан на реализацию. Потом всплывают вопросы вроде: "почему это view не может работать без базы данных".
Так вот этот класс в контексте этого топика я называю репозиторием.

B>>"БД ориентированое" приложение это то которое оперирует таблицами данных, а не деревьями объектов?
IB>Это те, где нет нетривиальной бизнеслогики, которую удобно выражать через сложные ОО конструкции. В моей практике таковых подавляющее большинство..
ОК. Я тебя понял. Твои аргумент ы не лешины смысла. Замечу все же что на большинстве проектов с которыми мне приходитс иметь дело удобно иметь именно ОО Иерархии модели. Нежели получать десяток не связанных сущностей для вывода на View.

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

T>ссылки != прокси, ссылка может быть обычной прямой ссылкой, прокси надо только для lazy-loading больших коллекций и больших объектов, если надо ограничить выгружаемое дерево на клиентскую сторону (или за скоп транзакции). Следить надо только за двумя вещами — за тем, чтобы ограничить выбираемое дерево и за тем, чтобы не было попытки обратиться к прокси вне границ транзакции (когда сессия с коннектом уже умерла). Обе проблемы решаются.
T>Про транзакционность и кэширование поясни, что имел ввиду. Вроде есть кэширование первого уровня (в контексте сессии) и второго (какой-нибудь сторонний TreeCache). Я обычно использую короткие транзакции (запрос-начало транзакции-обработка-конец транзакции-отдача данных), хотя можно использовать extended context (session) и conversation model. Вроде все живы Не вижу проблемы.
В принципе ты ответил на все вопросы, только их придется немного дополнить. Итак, у нас при Lazy Load задействуются 3 механизма — загрузка, транзакционность, кэширование. Насчет транзакционности — есть некоторое дополнительное правило. Объект в контексте транзакции не должен загружаться несколько раз (если конечно у тебя не явный блокировочный механизм, типа serialize транзакции БД). Не должно существовать два экземпляра одного объекта. Так как один объект может быть изменен(в контексте этой или другой транзакции), то другой объект имеет неверное состояние. Такие транзакции редкость, но если они встречаются, то Lazy Load нам мешает. Так как у нас нет явного механизма управления загрузкой, то должен быть построен механизм предотвращающий повторную загрузку объекта. А это также обозначает, что кэш первого уровня — это не контекст сессии, а контекст транзакции. Проблемы корректности общего кэша, описывать не буду. Они едины как с Lazy Load так и без оного.

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

Извини немного отвлекся. Что касается ссылок. Как результат, если у нас есть ссылка, то обрабатывать отдельно объект мы уже не сможем. В результате, при подгрузке — связанный объект всегда попадает в контекст транзакции. И для него придется выполнять все правила транзакционности. Ну заменили у Сustomer физический адрес. А в этот момент идут транзакции сохранения заказов. Версии не совпадают, транзакция заказов — откатывается. Кэширование. Кэширование идет практически всегда по ID. Вообще, в большинстве случаев, если тебе нужен тот или иной объект, то ты его ищешь в кэше по ID. Но объект сам по себе подвешен на ссылке родительского, и адресуется именно через родительский ID. Это не только неприятная нагрузка на кэш, но и требует чтобы при загрузке в кэш, мы проходили по всем идентификаторам.
Вобщем — удобства тут особо не вижу. Особенно в системах запрос-чтение-ответ. И в случае с производительностью — по сравнению с БД, работа с ссылками или hash таблицами нивелирована.

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

IB>>А если нужны? Или, повторюсь, структура объекта другая?
B>Такая же структура.
Этого нельзя гарантировать, в общем случае она может быть произвольной.

B> Но в той же структуре данных без проксей. То что ему не нужно в этой структуре null.
То етсь не до конца инициализированный объект — а вот это уже конкретный косяк.

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

B> но таскать их мы с собой не можем, так как у объектов модели нет ссылок.
Да можем. Они офигительно таскаются куда надо в любых вариантах именно потому что у них нет ссылок и они не тянут за собой никаких потрохов.

B>Мне не нужен класс доступа к данным, мне нужен класс для связывания объектов модели.
Не нужно тебе их связывать. Нужно просто достать конкретный объект на основе другого, как именно это сделать, с помощю какого сервиса и откуда — гораздо лучше знает потребитель, а не сам объект.

B> Размазывать DAO по всем слоям гораздо хуже чем проделывать тоже самое с репозиторием.
Да не размазывается там ничего, я уже писал. Про репозиторий/DAL знает только BL.

B> DAO сильно завязан на реализацию. Потом всплывают вопросы вроде: "почему это view не может работать без базы данных".
Не всплывают, так как view отлично работает без DAL.

А>Есть класс заказа — Order. У заказа есть клиент, т.е. Customer. Так вот в классе Order хранить ли объект типа Customer? Или хранить CustomerID?

Только ссылку, будет это программная ссылка или ID — вопрос реализации.

А>Допустим, что все-таки правильнее хранить в классе Order объект типа Customer, а не CustomerID, тогда как загружать заказ из БД? Одним запросом с джоином из таблицы клиентов или отдельно загрузить данные только из таблицы заказов а потом отдельным запросом типа

Одним запросом можно заполнять составной набор данных (в .NET датасет из нескольких таблиц). Как это реализовывать в процедуре на базе — не важно, главное, чтобы оптимально по производительности.

А>Второй вопрос по задаче Order и OrderLine. Хранить ли IList<OrderLine> OrderLines в классе Order или нет? Если да, то как правильнее организовать работу? Когда загружать? А если в заказе 1000 позиций? А может они нам не понадобятся?

По месту.

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

OK. Ты меня практически убедил. Единственное что останусь при мнении что вариант с ID тоже не лишен недостатков. У меня такой вопрос. Есть где opensource решение или пример проекта посмотреть этот подход в действии?

По поводу Customer vs CustomerID.
Допустим надо отобразить все заказы за сегодня, или за неделю и т.д. Таких заказов может быть 1000. Может больше. В случае если мы храним Customer, то мы можем забайндить и отображать order.Customer.Name. В случае с CustomerID — уже облом, не судьба будет увидеть имя клиента. Так что видимо хранение CustomerID отпадает, и надо делать либо LazyLoad с кешем на Customer, либо грузить его сразу.

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

B>Единственное что останусь при мнении что вариант с ID тоже не лишен недостатков.
Естетсвенно, серебряных пуль не существует и все имеет свою, довольно ограниченную, область применения.

B>У меня такой вопрос. Есть где opensource решение или пример проекта посмотреть этот подход в действии?

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

MC>По поводу Customer vs CustomerID.
MC>Допустим надо отобразить все заказы за сегодня, или за неделю и т.д. Таких заказов может быть 1000. Может больше. В случае если мы храним Customer, то мы можем забайндить и отображать order.Customer.Name. В случае с CustomerID — уже облом, не судьба будет увидеть имя клиента. Так что видимо хранение CustomerID отпадает, и надо делать либо LazyLoad с кешем на Customer, либо грузить его сразу.

Либо биндить не объекты DAL, а какой-нибудь OrderList который будет представлять данные в нужном виде.

Здравствуйте, Константин Б., Вы писали:

КБ>Здравствуйте, MozgC, Вы писали:

MC>>По поводу Customer vs CustomerID.
MC>>Допустим надо отобразить все заказы за сегодня, или за неделю и т.д. Таких заказов может быть 1000. Может больше. В случае если мы храним Customer, то мы можем забайндить и отображать order.Customer.Name. В случае с CustomerID — уже облом, не судьба будет увидеть имя клиента. Так что видимо хранение CustomerID отпадает, и надо делать либо LazyLoad с кешем на Customer, либо грузить его сразу.

КБ>Либо биндить не объекты DAL, а какой-нибудь OrderList который будет представлять данные в нужном виде.

Этому OrderList'у видимо так же придется обращаться к БД (DAL) чтобы получить инфу для отображения, например имя клиента по его ID. Опять же падение производительности. Хотя в случае использования кеша может быть и небольшое. Т.е. эта ситуация похожа на LazyLoad с кешем.

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

MC>Здравствуйте, Константин Б., Вы писали:



КБ>>Либо биндить не объекты DAL, а какой-нибудь OrderList который будет представлять данные в нужном виде.

MC>Этому OrderList'у видимо так же придется обращаться к БД (DAL) чтобы получить инфу для отображения, например имя клиента по его ID. Опять же падение производительности. Хотя в случае использования кеша может быть и небольшое. Т.е. эта ситуация похожа на LazyLoad с кешем.

Там можно сделать очень по разному. Никто не мешает загрузить сразу всех кастомеров оставивших заказы за сегодня, неделю и т. д. Это самый быстрый вариант. Главное что UI больше не зависит от того откуда что берется.

Вопрос к IB:

Я так понял, вы в основном храните ID в своих объектах, а не агрегируете другой объект.
Как быть тогда в случае с отображением данных во View?

Например есть OrderLine, у которого есть CustomerID, ManufacturerID, DealerID, ReferencePersonID и т.д., на практике может встретиться еще и похлеще. И надо отобразить например 1000 таких OrderLine. Как такое отображаете?

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

MC>Вопрос к IB:
А можно я отвечу?

MC>Я так понял, вы в основном храните ID в своих объектах, а не агрегируете другой объект.
MC>Как быть тогда в случае с отображением данных во View?
MC>Например есть OrderLine, у которого есть CustomerID, ManufacturerID, DealerID, ReferencePersonID и т.д., на практике может встретиться еще и похлеще. И надо отобразить например 1000 таких OrderLine. Как такое отображаете?

Вариантов вроде не один.
1) Репозиторий уезжает на view где используется так же как и в сервисах.
2) View имеет другую модель данных, которая создается, например, контроллером. Отдельная модель для view, ИМХО, один из немногих случаев обоснованого создания новой модели классов для той же модели данных.
3) Данные на View улетают в простом подготовленном виде, но без новых иерархий и репозиториев. Например несколькими массивами.

MC>>Вопрос к IB:
B>А можно я отвечу?
Ну я даже не знаю...

MC>>Я так понял, вы в основном храните ID в своих объектах, а не агрегируете другой объект.
MC>>Как быть тогда в случае с отображением данных во View?
MC>>Например есть OrderLine, у которого есть CustomerID, ManufacturerID, DealerID, ReferencePersonID и т.д., на практике может встретиться еще и похлеще. И надо отобразить например 1000 таких OrderLine. Как такое отображаете?

B>Вариантов вроде не один.
B>1) Репозиторий уезжает на view где используется так же как и в сервисах.

Не понял, можно подробнее?

B>2) View имеет другую модель данных, которая создается, например, контроллером. Отдельная модель для view, ИМХО, один из немногих случаев обоснованого создания новой модели классов для той же модели данных.

Имеешь в виду создание класса типа OrderLineView и конвертацию списка OrderLine в OrderLineView?

B>3) Данные на View улетают в простом подготовленном виде, но без новых иерархий и репозиториев. Например несколькими массивами.

Тут тоже можно, пожалуйста, поподробнее?

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

B>>1) Репозиторий уезжает на view где используется так же как и в сервисах.
MC>Не понял, можно подробнее?
ОК. Код в слое View обращается непосредственно к репозиторию чтобы достать Customer(.Name) имея Order.CustomerID/

B>>2) View имеет другую модель данных, которая создается, например, контроллером. Отдельная модель для view, ИМХО, один из немногих случаев обоснованого создания новой модели классов для той же модели данных.
MC>Имеешь в виду создание класса типа OrderLineView и конвертацию списка OrderLine в OrderLineView?
Да. OrdersScreen, OrdersForms etc.

B>>3) Данные на View улетают в простом подготовленном виде, но без новых иерархий и репозиториев. Например несколькими массивами.
MC>Тут тоже можно, пожалуйста, поподробнее?
Примерно такой код в контроллере:

prepareOrderList(Order[] orders)
{
   Customer[] customers = repository.getSortedCustomers(orders);
   MVCView.render(orders, customers);
}

Тут ещё некоторая двоякость термина View присутствует. Есть view как слой отоброжения данных (слой уровня Service, DAL).
А есть view — как слой паттерна MVC. Где MVC всего лишь способ реализовать View слой приложения.

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

MC>Вопрос к IB:
А чего бы меня напрямую не спросить?

MC>Я так понял, вы в основном храните ID в своих объектах, а не агрегируете другой объект.
В основном да.

MC>Как быть тогда в случае с отображением данных во View?
Легко и непринужденно.

MC>Например есть OrderLine, у которого есть CustomerID, ManufacturerID, DealerID, ReferencePersonID и т.д., на практике может встретиться еще и похлеще. И надо отобразить например 1000 таких OrderLine. Как такое отображаете?
OrderLine — это объект для отображения агрегатной информации о заказе? Для отображения ID-шники, очевидно, не нужны, поэтому, скорее всего, объект будет иметь вид:
OrderLine
{
...
OrderId,
CustomerName,
ManufacturerName,
DealerName,
ReferencePersonName,
...
}
А в пределе — это может быть вообще анонимный тип.

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

MC>>Вопрос к IB:
IB>А чего бы меня напрямую не спросить?

Напрямую это как?

MC>>Например есть OrderLine, у которого есть CustomerID, ManufacturerID, DealerID, ReferencePersonID и т.д., на практике может встретиться еще и похлеще. И надо отобразить например 1000 таких OrderLine. Как такое отображаете?
IB>OrderLine — это объект для отображения агрегатной информации о заказе?

OrderLine — это класс объекта представляющий конкретную линию (позицию) заказа, т.е. заказ Order включает в себя список позиций OrderLine, а так же общую информацию о заказе, типа номер заказа, дата заказа и т.д.

IB> Для отображения ID-шники, очевидно, не нужны, поэтому, скорее всего, объект будет иметь вид:
IB>OrderLine
IB>{
IB> ...
IB> OrderId,
IB> CustomerName,
IB> ManufacturerName,
IB> DealerName,
IB> ReferencePersonName,
IB> ...
IB>}
IB>А в пределе — это может быть вообще анонимный тип.

У нас наверное расхождение в понятиях. Вы, насколько я понимаю, представили OrderLine как класс специально созданный для отображения в гриде. Если да, то как вы создаете объекты такого типа и заполняете их? Если нет, то как вы например сохраняете такой объект в БД, если там имена а не ID из БД?

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

MC>Напрямую это как?
Напрямую — это ответ на мое сообщение, а не Константин-а Б.

MC>OrderLine — это класс объекта представляющий конкретную линию (позицию) заказа, т.е. заказ Order включает в себя список позиций OrderLine, а так же общую информацию о заказе, типа номер заказа, дата заказа и т.д.
Ну, значит там будет еще ProductId фигурировать, ну или OrderLineId, если речь не о продуктах, а о какой-то абстрактной позиции...

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

MC>Если да, то как вы создаете объекты такого типа и заполняете их?
Например так:

var lines = from o in orders 
            from c in customers
            ...
            where o.orderId == ... 
            select new {c.CustomerName, ...};

Или так:

OrderLines lines = Dal.GetOrderLinesByOrderId(orderId);

MC>Если нет, то как вы например сохраняете такой объект в БД, если там имена а не ID из БД?
Так как объект плоский, то по OrderLineId однозначно восстанавливаются все остальные ID-шники.

Я правильно понимаю что у вас 2 типа классов: один тип — обычный перенос сущности в ОО-вид, а другой — специально для отображения в гриде?

Т.е. если есть сущность "позиция заказа", то у вас будет класс OrderLine, который будет включать ManufacturerID, DealerID, ReferencePersonID и т.д., и класс например OrderLineGrid, который будет вместо ID содержать ManufacturerName, DealerName и т.д.?

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

IB>Например так:
IB>

IB>var lines = from o in orders 
IB>            from c in customers
IB>            ...
IB>            where o.orderId == ... 
IB>            select new {c.CustomerName, ...};
IB>

Иван, ну что за пряжки в сторону. Linq это же не показатель. Из твоего кода можно сделать вывод что ты загрузил заранее все orders, customers и теперь получаешь объекты по ID. Это не всегда возможно. Если не загрузил, то это ещё один метод в DAL. Зачем? Ну то есть не конкретно зачем этот один метод, а почему ты считаешь что приемлемо менять DAL в зависимости от того что в гриде отображается? Я считаю правильным передавать ID из веб-сервиса того же, это элементарно проще. Но вот в промежутке ClientDAL <-> ClientBLL уже только объекты должны быть. Разве нет?