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

A>Иван, ну что за пряжки в сторону.
??

A> Linq это же не показатель.
Это почему это?
Одна из поблем такого подхода в том, что, в предельном случае, на каждый запрос нужно создавать свой тип данных, Linq позволяет легко это обойти.

A> Из твоего кода можно сделать вывод что ты загрузил заранее все orders, customers и теперь получаешь объекты по ID.
Нельзя сделать такого вывода, Linq-овские запросы не плохо транслируются в БД.

A> Если не загрузил, то это ещё один метод в DAL.
Это не метод, это еще один способ обращения к DAL, равно как и клюбому другому сервису оперирующему коллекциями. Можно, конечно, назвать это и методом в некотором приближении, но все-таки это не совсем корректно.

A> Ну то есть не конкретно зачем этот один метод, а почему ты считаешь что приемлемо менять DAL в зависимости от того что в гриде отображается?
Я не меняю DAL, я прежде всего, меняю объект однако вовсе не факт, что это приведет к изменениям в DAL.

A> Но вот в промежутке ClientDAL <-> ClientBLL уже только объекты должны быть. Разве нет?
какие объекты, в каком виде?

Смотри: Допустим у тебя есть полноценный объект OrderLine, у него вложенные объекты Customer, Manufacture, ect.., у Customer-а еще адрес какой-нибудь..
Теперь тебе надо отобразить тот же самый список — как ты весь этот зоопарк из базы грузить будешь? В этом случае у View нет формального контракта, что ему надо, а что нет — ты вынужден грузить все дерево и одним запросом уже не отделаешься. То есть, на практике, конечно, так не делают и грузят только то что надо, объект получается инициализирован не до конца, DAL, в конечном итоге, все равно меняется под View, но теперь, если View сломался потому что данных не хватает — концов не найдешь, плюс DAL стал заметно сложнее и у View появилась лишняя логика. Ну и зачем это надо?

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

MC>Я правильно понимаю что у вас 2 типа классов: один тип — обычный перенос сущности в ОО-вид, а другой — специально для отображения в гриде?
Нет такого класса, просто для перевода сущности в ОО-вид. Есть просто плоские данные и набор сервисов, которые этими данными обмениваются. View-сервис отображения, DAL — сервис персистентного хранения, какой-нибудь WebService — сервис коммуникации... Если одному из сервисов нужны данные в определенном виде, то он их получит.

MC>Т.е. если есть сущность "позиция заказа", то у вас будет класс OrderLine, который будет включать ManufacturerID, DealerID, ReferencePersonID и т.д.,
Если такой класс не будет нужен ни одному из сервисов, то такого класса не будет.

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

A>> Если не загрузил, то это ещё один метод в DAL.
IB>Это не метод, это еще один способ обращения к DAL, равно как и клюбому другому сервису оперирующему коллекциями. Можно, конечно, назвать это и методом в некотором приближении, но все-таки это не совсем корректно.

Ну лишний SQL запрос со всеми своими проблемами (а не блокирует ли этот запрос другие, а индексированы ли столбцы) добавляется.

A>> Но вот в промежутке ClientDAL <-> ClientBLL уже только объекты должны быть. Разве нет?
IB>какие объекты, в каком виде?

Любые объекты, главное что не идентификаторы.

IB>Смотри: Допустим у тебя есть полноценный объект OrderLine, у него вложенные объекты Customer, Manufacture, ect.., у Customer-а еще адрес какой-нибудь..
IB>Теперь тебе надо отобразить тот же самый список — как ты весь этот зоопарк из базы грузить будешь?

LazyLoad с возможным упреждающим чтением. Скажем если у меня попросили Manufacturer, очевидно, лучше считать всех сразу, а не по одному. Всё равно их мало, а понадобятся почти все.

IB>В этом случае у View нет формального контракта, что ему надо, а что нет — ты вынужден грузить все дерево и одним запросом уже не отделаешься.

Да я не фанатею от того чтобы грузить всё именно одним запросом. Просто количество запросов не должно быть пропорционально количеству объектов. А количеству типов объектов, запросто.

IB>То есть, на практике, конечно, так не делают и грузят только то что надо, объект получается инициализирован не до конца, DAL, в конечном итоге, все равно меняется под View, но теперь, если View сломался потому что данных не хватает — концов не найдешь,

Если данных не хватает они будут просто подгружены по требованию.

IB>плюс DAL стал заметно сложнее и у View появилась лишняя логика. Ну и зачем это надо?

DAL сложнее стал, View — нет.

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

A>Ну лишний SQL запрос со всеми своими проблемами (а не блокирует ли этот запрос другие, а индексированы ли столбцы) добавляется.
Он не лишний, эти данные все равно доставать. При этом он создаст гораздо меньше проблем, так как достает данные сразу в том виде в каком надо и одним запросом, что, как минимум, снимает вопрос их консистентности и максимально эффективно. А по идентификаторам индексы и так есть..

A>Любые объекты, главное что не идентификаторы.
Ну объекты разными могут быть, могут плоскими, могут иерархическими — тебе без разницы, лишь бы объекты? И чем идентификаторы помешали?
При этом, заметь, у меня идентификаторов тоже не дофига.

A>LazyLoad с возможным упреждающим чтением.
А не дофига ли логики для такой, вообщем-то тривиальной задачи? При этом ты автоматом лишаешься возможности передать свой объект в другое окружение (допустим View стал удаленным), и добавляешь кучу геморроя на ровном месте, по обслуживанию всей этой кухни?

A> Скажем если у меня попросили Manufacturer, очевидно, лучше считать всех сразу, а не по одному. Всё равно их мало, а понадобятся почти все.
У тебя попросили его автоматом, при попытке показать список продуктов в заказе... Загружать его в каждый продукт? Или строить модель со ссылками на уникального производителя из всех продуктов?
И что будешь делать, когда появится новый производитель или изменится одна из характеристик? Это бывает редко, но это тоже надо обрабатывать.

A>Да я не фанатею от того чтобы грузить всё именно одним запросом.
А может стоило бы?..

A> Просто количество запросов не должно быть пропорционально количеству объектов. А количеству типов объектов, запросто.
Ну, смотри что получается: Строим мы красивую объектную модель безовсяких Id-шников. View она в таком виде не нужна, он все равно показывает ее плоско и по частям. Может быть вебсервису? Фигушки, там тоже довольно ограниченный набор данных нужен и опять-таки немного в другом виде. DAL, очевидно, ваще в пролете... Так ради кого вся эта красота?
Может быть это удобное универсальное представление, которое бизнес-логику продукта отражает и от этого всем хорошо? Давай попробуем на примере:
Вот есть у нас заказ, у заказа список продуктов, а у каждого продукта имеется Manufacturer, (у которого, в свою очередь, кстати, адрес фактический, адрес юридический, контактное лицо, список контрактов имеются, тоже ни разу не плоские объекты)... Ну, допустим, построили мы весь этот баобаб. Хорошо ли работается сейлзу? Да вообщем-то не плохо, иерархия ему привычная и насквозь удобная... И все бы зашибись, но тут приходит менеджер по закупкам, которому иерархия нужна ровно обратная Manufacturer, у которого по мимо адресов должен быть список производимых продуктов, а у каждого продукта список заказов... И где наша афигительная объектная модель? Очевидно с удобством представления тоже наелись.

Вышеприведенный пример наглядно демонстрирует тезис, что Data != Object. Данные — это данные, даже в объектном мире и не надо делать из них объекты. При однойи той же семантике, интерпретация данных может менятся, в зависимости от контекста, а упаковывая данные в сложный объект, ты прибиваешь гвоздями к данным конкретную трактовку. И потом приходится мучительно отдирать одно от другого.

A>Если данных не хватает они будут просто подгружены по требованию.
Это если ты озаботился это дело написать, что само по себе не тривиальная и совершенно отдельная задача. При этом вся эта ленивость, в данном случае, является откровенной борьбой с собственноручно созданными проблемами.

A>DAL сложнее стал, View — нет.
Как раз View-то в первую очередь стал сложнее. Нет формального контракта, декларирующего что именно он должен показывать и теперь именно в представлении болтается логика извлечения из развесистого объекта необходимых для показа данных в нужном виде. Приэтом протестировать эту логику так просто уже не получится.

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

IB>Он не лишний, эти данные все равно доставать. При этом он создаст гораздо меньше проблем, так как достает данные сразу в том виде в каком надо и одним запросом, что, как минимум, снимает вопрос их консистентности и максимально эффективно. А по идентификаторам индексы и так есть..

Не-не, это заблуждение. Один запрос ничем не лучше трёх. Если ты пытаешь поменять фамилию пользователя, а его в этот момент удалили, никакой супер-запрос тебе не поможет. Целостность данных вообще другими методами разруливается.

IB>Ну объекты разными могут быть, могут плоскими, могут иерархическими

Уточни что такое в твоём понимании плоские объекты и иерархические.

A>>LazyLoad с возможным упреждающим чтением.
IB>А не дофига ли логики для такой, вообщем-то тривиальной задачи? При этом ты автоматом лишаешься возможности передать свой объект в другое окружение (допустим View стал удаленным), и добавляешь кучу геморроя на ровном месте, по обслуживанию всей этой кухни?

Почему лишаюсь? Просто вся эта кухня достаточно высоко (DAL клиента, читай Web-Service Client). Плюс я на самом деле экономлю ресурсы (тот же трафик), так как не считываю одни и те же данные в разных наборах. Имя клиента в списке клиентов и имя клиента в списке покупок дважды считаны не будут. Да и хранится они не будут дважды.

A>> Скажем если у меня попросили Manufacturer, очевидно, лучше считать всех сразу, а не по одному. Всё равно их мало, а понадобятся почти все.
IB>У тебя попросили его автоматом, при попытке показать список продуктов в заказе... Загружать его в каждый продукт? Или строить модель со ссылками на уникального производителя из всех продуктов?

У меня в клиенте (там где View) объект Product ссылается на объект Manufacturer. Если производитель один и тот же, то и ссылка на один и тот же (а не одинаковые!) объект.

IB>И что будешь делать, когда появится новый производитель или изменится одна из характеристик? Это бывает редко, но это тоже надо обрабатывать.

А вот тут как раз всё хорошо. Пишем что-то вроде

bool SetAddress(
    Manufacturer manufacturer,
    string address)
{
    bool result = this._accessor.WebService.SetAddress(manufacturer.ID, address);

    if (result)
    {
        manufacturer.Address = address;
    }
    else
    {
        throw new DataAccessException(...);
    }
}

Объект manufacturer для конкретного производителя только один. Присваивание manufacturer.Address сгенерирует событие PropertyChanged, всякие IBindingList и компания сгенерируют Change (уже для всего объекта), View обновятся.

IB>Ну, смотри что получается: Строим мы красивую объектную модель безовсяких Id-шников. View она в таком виде не нужна, он все равно показывает ее плоско и по частям. Может быть вебсервису? Фигушки, там тоже довольно ограниченный набор данных нужен и опять-таки немного в другом виде. DAL, очевидно, ваще в пролете... Так ради кого вся эта красота?

Ку-ку, ID у веб-сервиса есть. Их только после DAL клиента нет.

IB>Вот есть у нас заказ, у заказа список продуктов, а у каждого продукта имеется Manufacturer, (у которого, в свою очередь, кстати, адрес фактический, адрес юридический, контактное лицо, список контрактов имеются, тоже ни разу не плоские объекты)... Ну, допустим, построили мы весь этот баобаб. Хорошо ли работается сейлзу? Да вообщем-то не плохо, иерархия ему привычная и насквозь удобная... И все бы зашибись, но тут приходит менеджер по закупкам, которому иерархия нужна ровно обратная Manufacturer, у которого по мимо адресов должен быть список производимых продуктов, а у каждого продукта список заказов... И где наша афигительная объектная модель? Очевидно с удобством представления тоже наелись.

Не, ты тёплое с мягким не путай. Я нигде и не говорил что данная модель позволит тебе удобно искать во всех направлениях. поиск всех продуктов выпускаем данным производителем ты, конечно, получишь у БД. Просто уже можно просить только ID, остальная информация будет восстановлена на клиенте.

IB>Вышеприведенный пример наглядно демонстрирует тезис, что Data != Object.

Вышеприведённый пример ничего не демонстрирует, ты не понял того что я говорю и благополучно доказал недостатки чего-то другого.

A>>Если данных не хватает они будут просто подгружены по требованию.
IB>Это если ты озаботился это дело написать, что само по себе не тривиальная и совершенно отдельная задача. При этом вся эта ленивость, в данном случае, является откровенной борьбой с собственноручно созданными проблемами.

if (!cache.ContainsKey(object.ID))
{
    ReloadCache()
}

?
столько я всегда напишу.

A>>DAL сложнее стал, View — нет.
IB>Как раз View-то в первую очередь стал сложнее. Нет формального контракта, декларирующего что именно он должен показывать и теперь именно в представлении болтается логика извлечения из развесистого объекта необходимых для показа данных в нужном виде. Приэтом протестировать эту логику так просто уже не получится.

Ну если обращение к свойству объекта это "логика извлечения из развесистого объекта необходимых для показа данных в нужном виде", то конечно да. Хотя так пафосно я бы не называл, это всё в дизайнере прямо делается

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

A> Если ты пытаешь поменять фамилию пользователя, а его в этот момент удалили, никакой супер-запрос тебе не поможет.
Не передергивай. Здесь идет чтение набора, а не изменение одной записи и здесь один запрос от трех очень сильно отличается — это я тебе как краевед говорю.

A> Целостность данных вообще другими методами разруливается.
=)

A>Уточни что такое в твоём понимании плоские объекты и иерархические.
Плоский — содержит только примитивные типы, а иерархический любые сколь угодно сложные стуктуры.

A>Почему лишаюсь? Просто вся эта кухня достаточно высоко (DAL клиента, читай Web-Service Client).
То есть, тебе эту логику еще отдельно на клиенте реализовывать надо, без нее у тебя этот объект просто не заработает — вот по этому и лишаешься.

A>У меня в клиенте (там где View) объект Product ссылается на объект Manufacturer. Если производитель один и тот же, то и ссылка на один и тот же (а не одинаковые!) объект.
Вот именно, и вот эту identity тебе тоже обеспечивать надо, она из воздуха не возьмется.

A>А вот тут как раз всё хорошо.
Хитрый какой.. Не мужик, когерентность кеша так просто не обеспечивается. Как минимум у тебя должна быть гарантия, что все изменения будут делаться из одного места, что не всегда возможно, особенно если система распределенная. Потом тебе придется делать нотификацию всех заинтересованных кешей и гарантировать, что изменения обязательно доедут до базы... И это если еще не надо брать в расчет, что истоию изменений тоже бывает нужно хранить, скажем, до такого-то числа счета слали по такому-то адресу, а потом стали по другому...

A>Ку-ку, ID у веб-сервиса есть. Их только после DAL клиента нет.
Причем здесь ID?

A>Не, ты тёплое с мягким не путай.
??

A> Я нигде и не говорил что данная модель позволит тебе удобно искать во всех направлениях.
Внимание, главный вопрос топика: Так зачем она нужна?

A> поиск всех продуктов выпускаем данным производителем ты, конечно, получишь у БД.
Мне не нужен поиск, мне с производителем работать надо. Это тоже у БД?

A> Просто уже можно просить только ID, остальная информация будет восстановлена на клиенте.
Откуда она там возьмется и в каком виде она там лежит? И зачем просить ID отдельно, раундтрипы штука дорогая...

A>Вышеприведённый пример ничего не демонстрирует, ты не понял того что я говорю и благополучно доказал недостатки чего-то другого.
А что ты говоришь?

A>столько я всегда напишу.
Столько, к сожалению, не достаточно.

A>Ну если обращение к свойству объекта это "логика извлечения из развесистого объекта необходимых для показа данных в нужном виде", то конечно да.
Ты забыл про свой LazyLoading и другие ритуальные приседания.

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

A>> Если ты пытаешь поменять фамилию пользователя, а его в этот момент удалили, никакой супер-запрос тебе не поможет.
IB>Не передергивай. Здесь идет чтение набора, а не изменение одной записи и здесь один запрос от трех очень сильно отличается — это я тебе как краевед говорю.

Просто не надо один запрос выставлять как решение проблемы.

A>>Почему лишаюсь? Просто вся эта кухня достаточно высоко (DAL клиента, читай Web-Service Client).
IB>То есть, тебе эту логику еще отдельно на клиенте реализовывать надо, без нее у тебя этот объект просто не заработает — вот по этому и лишаешься.

Не отдельно. ТОЛЬКО на клиенте.

IB>Хитрый какой.. Не мужик, когерентность кеша так просто не обеспечивается. Как минимум у тебя должна быть гарантия, что все изменения будут делаться из одного места, что не всегда возможно, особенно если система распределенная. Потом тебе придется делать нотификацию всех заинтересованных кешей и гарантировать, что изменения обязательно доедут до базы... И это если еще не надо брать в расчет, что истоию изменений тоже бывает нужно хранить, скажем, до такого-то числа счета слали по такому-то адресу, а потом стали по другому...

В конкретном приложении для конкретного типа объектов кеш только один. Что касается многопользовательского изменения, то тут всё тоже решаемо. Во-первых, не удаляем ничего, только помечаем как удалённое. Тогда задание фамилии для удалённого пользователя будет восстанавливать пользователя. Во-вторых, пересчитываем кеш если в нём нет объекта с запрошенным ID. Только в очень экстремальных случаях этого не достаточно.

A>>Ку-ку, ID у веб-сервиса есть. Их только после DAL клиента нет.
IB>Причем здесь ID?

Ну ты же говоришь что ID у веб-сервиса нет, сразу объект. Я тебе говорю, что очень даже есть.

A>> Я нигде и не говорил что данная модель позволит тебе удобно искать во всех направлениях.
IB>Внимание, главный вопрос топика: Так зачем она нужна?

Во-первых, скрыть от Presentation и Business Logic детали загрузки данных. На уровне выше DAL эффективно загружать данные не создавая по запросу на каждый View практически нереальная задача. Да и зачем вопросы эффективной загрузки данных решать там?
Во-вторых, скрыть от Presentation и Business Logic детали хранения. ID мы вводим, как правило, специально, как удобное средство ссылки на объект. В предметной области есть очень даже однозначные PK, только они не числовые и работать с ними не удобно. Есть я, живой человек. То что я №2053 на РСДН — это проблема РСДН. У меня никакого номера в реальной жизни нет. У тебя тоже нет номера 343. Этот номер нельзя редактировать, нельзя смотреть. Никому кроме DAL он нафиг не нужен. Username тоже уникален, да только строка: и сравнивается дольше, и индексируется хуже, только от этого числовой идентификатор частью предметной области не становится.

A>> поиск всех продуктов выпускаем данным производителем ты, конечно, получишь у БД.
IB>Мне не нужен поиск, мне с производителем работать надо. Это тоже у БД?

Что значит работать? Ты развёрнуто задавай вопросы, мне угадывать трудновато.

A>> Просто уже можно просить только ID, остальная информация будет восстановлена на клиенте.
IB>Откуда она там возьмется и в каком виде она там лежит? И зачем просить ID отдельно, раундтрипы штука дорогая...

Ещё раз объясняю на более сложном примере. Один раз гружу и кеширую все товары, производителей и покупателей. Потом гружу продажи за май (производитель, товар, количество, покупатель, дата) и виде (ManufacturerID, ProductID, ProductCount, ClientID). Восстанавливаю объекты по ID из кеша. Гружу продажи за Июнь, за Апрель, клиенту Олег в полнолуние, в воскресные дни, в любой день с 12:00 до 14:00 и с сервера приходят уже только идентификаторы. Старт чуть дольше, работа заметно быстрее. Если пришёл ID которого в кеше нет, считываю данные в кеш заново. Выше DAL — сплошная непрекращающаяся объектная красота

IB>А что ты говоришь?

Что у меня объекты ТОЛЬКО на клиенте.

IB>Ты забыл про свой LazyLoading и другие ритуальные приседания.

А какое до этого всего дело View? Lazy Loading снаружи DAL не виден.

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

IB>Вот есть у нас заказ, у заказа список продуктов, а у каждого продукта имеется Manufacturer, (у которого, в свою очередь, кстати, адрес фактический, адрес юридический, контактное лицо, список контрактов имеются, тоже ни разу не плоские объекты)... Ну, допустим, построили мы весь этот баобаб. Хорошо ли работается сейлзу? Да вообщем-то не плохо, иерархия ему привычная и насквозь удобная... И все бы зашибись, но тут приходит менеджер по закупкам, которому иерархия нужна ровно обратная Manufacturer, у которого по мимо адресов должен быть список производимых продуктов, а у каждого продукта список заказов... И где наша афигительная объектная модель? Очевидно с удобством представления тоже наелись.

ИМХО, с proxy подходом "афигительная объектная модель" здесь будет нормально работать.

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

A>Просто не надо один запрос выставлять как решение проблемы.
Боже, Рома... Позволь тебе напомнить, что это ты нашел в одном запросе какие-то проблемы, а я лишь пытаюсь показать, что не надо высасывать их из пальца.

A>Не отдельно. ТОЛЬКО на клиенте.
Из твоих собщений я так и не понял о каком клиенте идет речь и что в этот момент происходит на сервере.

A>В конкретном приложении для конкретного типа объектов кеш только один.
Везет тебе, даже в ORM общего назначения обычно парочку прикручивают, на всякий слуай. =)

A> Что касается многопользовательского изменения, то тут всё тоже решаемо.
Естественно, все решаемо — вопрос зачем? Это все довольно серьезные усилия, требующие довольно аккуратной разработки, ради чего? Какую задачу решаем и с какой проблемой боремся?

A>Ну ты же говоришь что ID у веб-сервиса нет, сразу объект. Я тебе говорю, что очень даже есть.
Ты определенно сам с собой споришь.. Я нарисовал модель без ID-шника и сказал, что для веб-сервиса это не прокатит, а ты, в свою очередь, стал мне доказывать, что я не прав, потому что не прокатит, так как ID нужен. Это нормально? =)

A>Во-первых, скрыть от Presentation и Business Logic детали загрузки данных.
Детали загрузки скрыты и так, для этогоу нас есть DAL.

A> Да и зачем вопросы эффективной загрузки данных решать там?
Вопросы эффективности загрузки — задача сервиса хранения (DAL), задача BL — сформулировать для DAL в каком виде ему нужны данные.
А подход с объектами на данных скрывает и это от BL из-за чего приходится выдумывать различного рода приседания.

A>Во-вторых, скрыть от Presentation и Business Logic детали хранения.
Это ровно тоже самое, что и во-первых.
И какова цель у этого сокрытия? Сокрытие же не вещь в себе, какую проблему ты этим решаешь?

A>ID мы вводим, как правило, специально, как удобное средство ссылки на объект.
Объект у нас по определению должен обладать identity, это просто свойство любого объекта.

A> только от этого числовой идентификатор частью предметной области не становится.
Ну и что? Ты в серьез собираешься разруливать бизнес-логику оперируя только сущностями предметной области и не вводя дополнительных абстракций и вспомогательных механизмов?

A>Что значит работать?
Удалять, добавлять, редактировать. Это тоже делаем с БД или начинаем строить полноценную объектную модель?
Можешь сформулировать формальный критерий, когда с БД работаем, а когда начинаем дерево объектов городить?

A> Ты развёрнуто задавай вопросы, мне угадывать трудновато.
Ты не гадай, ты спрашивай..

A>Ещё раз объясняю на более сложном примере. Один раз гружу и кеширую все товары, производителей и покупателей.
Вообще-то номенклатура может быть очень дофигатой, все грузить будет накладно.

A>Потом гружу продажи за май (производитель, товар, количество, покупатель, дата) и виде (ManufacturerID, ProductID, ProductCount, ClientID).
О как. То есть ты вводишь еще один промежуточный слой, в кеше, который описывает все связи.... При этом твоя модель уже не является реляционной, но еще и не полноценная объектная... Просто некая вспомогательная структура для обслуживания ОО-модели, как я понимаю. Зачем такие сложности?

A> Выше DAL — сплошная непрекращающаяся объектная красота
Аж в дрожь бросает...

A>Что у меня объекты ТОЛЬКО на клиенте.
А на сервере что? Сборная солянка?

A>А какое до этого всего дело View? Lazy Loading снаружи DAL не виден.
А кто DAL сообщает, что надо загрузить?

Здравствуйте, <Аноним>, Вы писали:

А>Добрый день.

А>Посоветуйте, пожалуйста, как лучше и правильнее.

А>Есть класс заказа — Order. У заказа есть клиент, т.е. Customer. Так вот в классе Order хранить ли объект типа Customer? Или хранить CustomerID? Подозреваю, что правильнее первый вариант. Но второй вариант проще, иногда удобнее и быстрее. Например, из веб-сервиса нам может прийти объекта заказа с полем CustomerID т.к. веб-сервис не знает о типе Customer, и получается нам чтобы создать объект заказа типа Order нужно будет по CustomerID получать объект типа Customer (это будет занимать время, а потом информация о клиенте может и не понадобится). Как правильно?
Правильно — хранить реплику СustomerInfo внутри OrderInfo.
Наивные разработчики часто упускают фактор времени из моделирования. Дело в том, что клиент Иванова через полгода запросто может оказаться Синицыной. И что вы будете делать? По вашим отчетам, вы никогда ничего Ивановой не продавали. А у нее в руках есть распечатка, доказывающая обратное.
Или, вот к примеру, клиент ЗАО Сукин и Сыновья переехало в новый офис. А по вашим отчетам заказы пять лет назад были доставлены по адресу, которого на момент заказа не существовало в природе.

Конечно же, это не повод отказаться от сущности Customer совсем. Но такое дублирование информации позволит вам найти все заказы Синицыной, кем бы она там ни была в прошлом, и увидеть их такими, какими они были тогда.

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

B>ИМХО, с proxy подходом "афигительная объектная модель" здесь будет нормально работать.
При самом удачном раскладе, придется как минимум, разруливать циклические зависимости и вообще, стараться всеми силами на запутаться в связях. И ради чего все это?

IB, а как вы связываете объекты в программе если у вас только ID? Т.е. я так понимаю в вашей модели нет агрегации объектов. В классах Order, Customer и т.д. могут быть только простые типы? Я просто не могу представить в целом реализацию такой модели в проекте. Например вы создаете заказ:

...
Order order = new Order(...);
...
// Тут вы читаете в цикле например из excel-файла позиции заказа и создаете их
IList<OrderLine> orderLines = new List<OrderLine>();
...
OrderLine orderLine = new OrderLine(...);
...
orderLines.Add(orderLine);
...

Как вы связываете теперь Order и OrderLines? Или вы их не связываете, а просто сохраняете order в БД, после чего у него выставляется ID, а потом отдельно сохраняете orderLines, типа OrderLineRepository.AddOrderLines(order); ? Но связи кроме как "по смыслу" между объектами нет?

Про объектный подход с тянущимися иерархиями написано не так мало, а где можно почитать про реализацию подхода который используете вы?

MC>Или вы их не связываете, а просто сохраняете order в БД, после чего у него выставляется ID, а потом отдельно сохраняете orderLines, типа OrderLineRepository.AddOrderLines(order); ?

Опечатался, OrderLineRepository.AddOrderLines(order, orderLines); (ну или order.AddOrderLines(orderLines)) *

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

A>>Не отдельно. ТОЛЬКО на клиенте.
IB>Из твоих собщений я так и не понял о каком клиенте идет речь и что в этот момент происходит на сервере.

Клиент, это например, десктоп приложение обращающийся к веб-сервису. На сервере в этот момент происходит работа с плоскими объектами.

A>> Что касается многопользовательского изменения, то тут всё тоже решаемо.
IB>Естественно, все решаемо — вопрос зачем? Это все довольно серьезные усилия, требующие довольно аккуратной разработки, ради чего? Какую задачу решаем и с какой проблемой боремся?

Ну задача сохранения целостности данных вообще перпендикулярна обсуждаемому вопросу. Просто ты спросил, я ответил. Будут ли объекты на клиенте или ID, сути методов это не поменяет.

IB>И какова цель у этого сокрытия? Сокрытие же не вещь в себе, какую проблему ты этим решаешь?

Сокрытие не самоцель. Я уже говорил, экономятся ресурсы.

A>>ID мы вводим, как правило, специально, как удобное средство ссылки на объект.
IB>Объект у нас по определению должен обладать identity, это просто свойство любого объекта.

Да, но оно обычно уже есть в виде стрового имени. Ты 'Иван Бодягин', зачем нам ещё и 343? Можно и BLOB на 100Кб хранящий отпечаток пальца использовать, чем не identity?

IB>Ну и что? Ты в серьез собираешься разруливать бизнес-логику оперируя только сущностями предметной области и не вводя дополнительных абстракций и вспомогательных механизмов?

Не не 'только'. Просто я и пихать их везде где не надо, просто потому что они есть, не собираюсь.

IB>Удалять, добавлять, редактировать. Это тоже делаем с БД или начинаем строить полноценную объектную модель?
IB>Можешь сформулировать формальный критерий, когда с БД работаем, а когда начинаем дерево объектов городить?

БД и объекты не вместо, а вместе. Из-за того что у меня есть локальная копия данных, на сервер идут только запросы на запись. Изменения дублируются в локальном кеше. Случаи многопользовательской работы тоже достаточно просто разруливаются. В любом случае, объектный кеш тут ни мешает и не помогает.

A>>Ещё раз объясняю на более сложном примере. Один раз гружу и кеширую все товары, производителей и покупателей.
IB>Вообще-то номенклатура может быть очень дофигатой, все грузить будет накладно.

Ну можно грузить не всё, но всё же много. Что именно грузить, как оптимизировать, сильно зависит от природы объектов. Скажем продукты можно грузить группами по магазину, по производителю и т.п.

IB>О как. То есть ты вводишь еще один промежуточный слой, в кеше, который описывает все связи...

Ну да, кеш знает про связи объектов иначе как он их будет конструировать?

IB>При этом твоя модель уже не является реляционной, но еще и не полноценная объектная...

А чего ей по твоему не хватает для полноценности?

IB>Просто некая вспомогательная структура для обслуживания ОО-модели, как я понимаю. Зачем такие сложности?

Ну я сложностей-то особо не вижу. ИМХО по запросу на View — сложности. Запросов много, ими всеми надо руководить...

A>>Что у меня объекты ТОЛЬКО на клиенте.
IB>А на сервере что? Сборная солянка?

На сервере — ID и плоские объекты.

IB>А кто DAL сообщает, что надо загрузить?

Явно никто. DAL грузит всё, что уже нужно, но ещё не загружено.

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

MC>IB, а как вы связываете объекты в программе если у вас только ID?
По ID и связываю.

MC>Как вы связываете теперь Order и OrderLines? Или вы их не связываете, а просто сохраняете order в БД, после чего у него выставляется ID, а потом отдельно сохраняете orderLines, типа OrderLineRepository.AddOrderLines(order); ?
Так происходит в любом случае, БД-то никаких ссылок не знает, там есть только ID-шники.

MC>Про объектный подход с тянущимися иерархиями написано не так мало,
Мало. Про работу с данными в ОО вообще очень мало написано.

MC> а где можно почитать про реализацию подхода который используете вы?
Например, Фаулеровский TableGetway — это вот примерно оно.

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

A>Клиент, это например, десктоп приложение обращающийся к веб-сервису. На сервере в этот момент происходит работа с плоскими объектами.
А почему такое разделение? По какой причине десктопу удобнее работать с полной объектной моделью, вместо плоских данных?

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

A>Сокрытие не самоцель. Я уже говорил, экономятся ресурсы.
Так вот для чего сокрытие нужно!
Боюсь тут ты не угадал... Ресурсы можно экономить и при плоской модели, ровно с тем же успехом, если не с большим.

A>Да, но оно обычно уже есть в виде стрового имени. Ты 'Иван Бодягин', зачем нам ещё и 343?
Затем, что я могу поменять фамилию и все ссылки на меня отвалятся. Чем суррогатные ключи от естественных отличаются — знаешь?

A>Не не 'только'. Просто я и пихать их везде где не надо, просто потому что они есть, не собираюсь.
А где не надо и почему?

A>БД и объекты не вместо, а вместе.
В каком месте?

A> В любом случае, объектный кеш тут ни мешает и не помогает.
Зачем он тогда нужен?

A>Ну да, кеш знает про связи объектов иначе как он их будет конструировать?
Тут вопрос вызывает не само знание о связях, а то в каком виде они представлены. В базе ведь все лежит по другому, зачем этот промежуточный вариант? И зачем из них что-то конструировать? Мы уже выяснили, что сконструированная объектная модель к дальнейшнеу использованию, без изменений, не пригодна.. Так зачем?

A>А чего ей по твоему не хватает для полноценности?
Там ID-шники, вместо ссылок на объекты.

A>Ну я сложностей-то особо не вижу.
Сложности я тебе уже описал — ты устанешь все это в актуальном состоянии поддерживать, плюс с масштабируемостью у системы тоже будут проблемы.

A> ИМХО по запросу на View — сложности. Запросов много, ими всеми надо руководить...
А кто сказал, что плоская модель обязывает писать по запросу на представление?

A>На сервере — ID и плоские объекты.
А что мешает точно так же поступить на клиенте?

A>Явно никто. DAL грузит всё, что уже нужно, но ещё не загружено.
Откуда он узнает что нужно?

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

B>>ИМХО, с proxy подходом "афигительная объектная модель" здесь будет нормально работать.
IB>При самом удачном раскладе, придется как минимум, разруливать циклические зависимости и вообще, стараться всеми силами на запутаться в связях. И ради чего все это?
Циклические зависимости разруливаются на раз из-за того что объект уже прокеширован и в случае циклического обхода в кеше уже оказывает объект с нужными ссылками, цикл замыкает без какого-либо особого контроля над этим. Путаницы никакой особой нет. На сколько знаю из хибера есть только сложность с сопоставлением закешированых единичных объектов с закешироваными коллекциями.

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

A>>Клиент, это например, десктоп приложение обращающийся к веб-сервису. На сервере в этот момент происходит работа с плоскими объектами.
IB>А почему такое разделение? По какой причине десктопу удобнее работать с полной объектной моделью, вместо плоских данных?

У десктопа принципиально другие задачи. У него гораздо больше View представляющих разные комбинации свойств сущностей по-разному сгруппированные. Я не собираюсь тянуть это вниз до сервера. Если мне нужен ещё один View это не приведёт к изменению сервера.

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

В моём случае меняется вообще только клиент.

A>>Да, но оно обычно уже есть в виде стрового имени. Ты 'Иван Бодягин', зачем нам ещё и 343?
IB>Затем, что я могу поменять фамилию и все ссылки на меня отвалятся. Чем суррогатные ключи от естественных отличаются — знаешь?

Номер паспорта? У меня есть ещё и личный номер (не кино, а 01008018170, регистрационный номер меня как гражданина). И ты про отпечаток пальца забыл, BLOB на 100Кб.

A>>Не не 'только'. Просто я и пихать их везде где не надо, просто потому что они есть, не собираюсь.
IB>А где не надо и почему?

В интерфейсе не надо. Нигде на сайте нет числа 343.

A>>БД и объекты не вместо, а вместе.
IB>В каком месте?

Вместе в смысле не порознь, совместно, согласованно.

A>> В любом случае, объектный кеш тут ни мешает и не помогает.
IB>Зачем он тогда нужен?

Ну он не нужен для обеспечения целостности данных. Он нужен чтобы предоставить более высокостоящим слоям стабильный интерфейс прозрачной загрузки данных. Если какие данные нужны, они будут загружены эффективно и незаметно. Может не максимально эффективно а рамках одного запроса, зато весьма эффективно в рамках приложения, да и не надо что-либо переписывать при добавлении нового View.

IB>Тут вопрос вызывает не само знание о связях, а то в каком виде они представлены. В базе ведь все лежит по другому, зачем этот промежуточный вариант? И зачем из них что-то конструировать? Мы уже выяснили, что сконструированная объектная модель к дальнейшнему использованию, без изменений, не пригодна.. Так зачем?

Ну почему не пригодна? Очень даже пригодна. Для работы (удалить, добавить, поменять свойство) самое то.

A>>А чего ей по твоему не хватает для полноценности?
IB>Там ID-шники, вместо ссылок на объекты.

Да нет, там ссылки Я уже сто раз это написал. ID тоже хранятся, но только для общения с сервером.

A>>Ну я сложностей-то особо не вижу.
IB>Сложности я тебе уже описал — ты устанешь все это в актуальном состоянии поддерживать, плюс с масштабируемостью у системы тоже будут проблемы.

Да с масштабируемостью как раз всё лучше, так как меньше данных предаётся и запросов на чтение меньше гораздо. Это можно элементарно подсчитать. Плюс тут ещё и то, что сервер практически не трогается. Вот поддерживать на сервере запросы специфические для клиентских View можно действительно замучаться.

A>> ИМХО по запросу на View — сложности. Запросов много, ими всеми надо руководить...
IB>А кто сказал, что плоская модель обязывает писать по запросу на представление?

Тут дело не в том, что у тебя точно '1 view' <-> '1 query'. Тут дело в том, что у тебя количество запросов с ростом view вообще говоря растёт примерно линейно. У меня не растёт совсем.

A>>На сервере — ID и плоские объекты.
IB>А что мешает точно так же поступить на клиенте?

То что у клиента множество сложных View и мне всё равно придётся получать по ID объекты. Так лучше это сделать один раз при загрузке, чем миллион раз при отображении. А у сервера нет таких сложных View совсем.

A>>Явно никто. DAL грузит всё, что уже нужно, но ещё не загружено.
IB>Откуда он узнает что нужно?

Ну раз попросили, значит нужно Загрузили товары. У товара есть производитель №734. Если в кеше нет такого производителя, то грузим его, потому что нужно.
Если ты про оптимизации типа "нужно было показать только название производителя, а мы загрузили ещё и адрес", то это пустяки по сравнению с многократной загрузкой названия в разных комбинациях.

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

A> У него гораздо больше View представляющих разные комбинации свойств сущностей по-разному сгруппированные.
О! Вот плоская модель как раз и дает больше гибкости в формировании комбинаций и группировок свойств.

A>Я не собираюсь тянуть это вниз до сервера. Если мне нужен ещё один View это не приведёт к изменению сервера.
А с чего ты взял, что кешировать можно только полноценные объекты?

A>В моём случае меняется вообще только клиент.
Так у нас и так речь только о клиенте.

A> И ты про отпечаток пальца забыл, BLOB на 100Кб.
Я ничего не забыл — это все не дает 100% гарантии твоей идентичности в рамках независимой системы. Номер паспорта поменять легче чем фамилию — это все вообще азбука, ты еще ИНН какой-нибцдь вспомни или SSN.

A>В интерфейсе не надо. Нигде на сайте нет числа 343.
Так в интерфейс эти числа никто и не предлагает выводить.

A>Вместе в смысле не порознь, совместно, согласованно.
В каком месте они "не порознь" и как именно?

A>Он нужен чтобы предоставить более высокостоящим слоям стабильный интерфейс прозрачной загрузки данных.
Тоесть мы из модели получили интерфейс загрузки данных? забавно...

A> Может не максимально эффективно а рамках одного запроса, зато весьма эффективно в рамках приложения
Меня терзают смутные сомнения.

A>, да и не надо что-либо переписывать при добавлении нового View.
Не надо переписывать только в том случае, если ты уже написал всю инфраструктуру и, ключевое, имеющаяся иерархия объектов устраивает новый view.

A>Ну почему не пригодна?
Я описал почему. Потому что при той же семантике интерпретация данных может меняться в зависимости от контекста, а полная объектная модель такой гибкостью не обладает.

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

A>Да с масштабируемостью как раз всё лучше, так как меньше данных предаётся и запросов на чтение меньше гораздо.
Ты это будешь кластеру рассказывать.

A> Это можно элементарно подсчитать. Плюс тут ещё и то, что сервер практически не трогается. Вот поддерживать на сервере запросы специфические для клиентских View можно действительно замучаться.
....
A>Тут дело не в том, что у тебя точно '1 view' <-> '1 query'. Тут дело в том, что у тебя количество запросов с ростом view вообще говоря растёт примерно линейно. У меня не растёт совсем.
Пойми простую вешь — количество запросов к БД/серверу не зависит от представления объектов в памяти. Никак не зависит, вообще.
Просто создание полноценной объектной модели — это, в большинстве случаев, лишний промежуточный шаг и зачем его делать мне не понятно.

A>То что у клиента множество сложных View и мне всё равно придётся получать по ID объекты. Так лучше это сделать один раз при загрузке, чем миллион раз при отображении.
См выше.

A>Ну раз попросили, значит нужно
То есть кто-то таки должен попросить?

A>Если ты про оптимизации типа "нужно было показать только название производителя, а мы загрузили ещё и адрес", то это пустяки по сравнению с многократной загрузкой названия в разных комбинациях.
Да нет никакой многократной загрузки.

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

A>> У него гораздо больше View представляющих разные комбинации свойств сущностей по-разному сгруппированные.
IB>О! Вот плоская модель как раз и дает больше гибкости в формировании комбинаций и группировок свойств.

Ну тут как-то всё руками приходится делать. Непрозрачно.

A>>Я не собираюсь тянуть это вниз до сервера. Если мне нужен ещё один View это не приведёт к изменению сервера.
IB>А с чего ты взял, что кешировать можно только полноценные объекты?

Конечно не только, а смысл делать кучу кешей. Кеш юзеров без имени и фамилии, кеш юзеров без адреса и телефона, кеш юзеров с адресом, но без телефона... Да ну на фиг.

A>> И ты про отпечаток пальца забыл, BLOB на 100Кб.
IB>Я ничего не забыл — это все не дает 100% гарантии твоей идентичности в рамках независимой системы. Номер паспорта поменять легче чем фамилию — это все вообще азбука, ты еще ИНН какой-нибцдь вспомни или SSN.

Во-о-от. Но несмотря на удобство числового ID он частью предметной области всё равно не станет.

IB>Так в интерфейс эти числа никто и не предлагает выводить.

Я предлагаю Presentation даже не давать к ним обращаться. Ну так, заодно. Не самоцель.

A>>Вместе в смысле не порознь, совместно, согласованно.
IB>В каком месте они "не порознь" и как именно?

Объектная модель и данные в БД поддерживаются в согласованном состоянии без многократного считывания из БД.

A>>Он нужен чтобы предоставить более высокостоящим слоям стабильный интерфейс прозрачной загрузки данных.
IB>То есть мы из модели получили интерфейс загрузки данных? забавно...

Из DAL. DAL строит модель по требованию, так, чтобы все внешние ссылки были разрешены.

A>>, да и не надо что-либо переписывать при добавлении нового View.
IB>Не надо переписывать только в том случае, если ты уже написал всю инфраструктуру и, ключевое, имеющаяся иерархия объектов устраивает новый view.

А кто у View спрашивает, собственно? View 100 раз на дню меняется, под View менять внутренности замучаешься. Да и внутренности будут не очень.

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

Меня терзают смутные сомнения

A>>Да нет, там ссылки
IB>Вот потому и не полноценная объектная. Ты хоть нить разговора-то не теряй.

Я не понял. Нет ссылок, модель неполноценная. Есть ссылки (как у меня), модель всё равно неполноценная. Доктор, определяйтесь.

A>>Да с масштабируемостью как раз всё лучше, так как меньше данных предаётся и запросов на чтение меньше гораздо.
IB>Ты это будешь кластеру рассказывать.

А кластер тут причём? Кластер для клиента должен быть абсолютно прозрачен, иначе это наколеночная поделка.

A>>Тут дело не в том, что у тебя точно '1 view' <-> '1 query'. Тут дело в том, что у тебя количество запросов с ростом view вообще говоря растёт примерно линейно. У меня не растёт совсем.
IB>Пойми простую вешь — количество запросов к БД/серверу не зависит от представления объектов в памяти. Никак не зависит, вообще.

Не самих запросов, конечно. Извини, если запутал. Разных ТИПОВ запросов.

IB>Просто создание полноценной объектной модели — это, в большинстве случаев, лишний промежуточный шаг и зачем его делать мне не понятно.

Ну ты ИМХО преувеличиваешь трудоёмкость этого шага.

A>>Ну раз попросили, значит нужно
IB>То есть кто-то таки должен попросить?

Да, просьбой является неразрешённая внешняя ссылка (foreign key).

A>>Если ты про оптимизации типа "нужно было показать только название производителя, а мы загрузили ещё и адрес", то это пустяки по сравнению с многократной загрузкой названия в разных комбинациях.
IB>Да нет никакой многократной загрузки.

Ну как же нет, когда ты предлагаешь половинки объектов грузить.