igor_fle wrote:
> Здравствуйте, Козьма Прутков, Вы писали:
>
> КП>igor_fle wrote:
>
>>>Я не говорю, что-бы пол базы данных вытащить. Мы подходим к кастомизации DAL слоя, в зависимости от использования, для одной аппликации мне надо первых 20 полей таблицы, для второй мне другие нужны 20, а для 3 надо только одно поле, при сложных запросах комбинации возрастают, как в этих случаях правильно поступить?
>
> КП>ок. у тебя получается, что есть несколько приложений, шарящих одну базу
> КП>и больше никак не связанных? То есть у каждого свой набор БО, DAL и
> КП>т.д.? Интересно... Это уже про интеграцию тогда надоть почитать, а не
> КП>рассуждать о мепперах и организации DAL и иже с ним.
>
> Ну почему интеграция. Есть администрация, которая заносит, редактирует данные ит.д.
> Есть сайт для юзеров, на нём можно увидеть всё, что делает администрация. Есть разные другие аппликации, которые согдают файлы в разных форматах, по интересующей юзера информации и занимаются рассылкой, есть разные batch, которые делают разную работу то подсчётам и обработке различной информации. Но все они работают с одной базой, значит и БО у всех должны быть одинаковые, и быть доступными для всех. Интеграция нужна если разные источники, базы ит.д.

ну, на самом деле, паттерн интеграции Shared Database никто не отменял
Да, в данном случае, я абсолютно согласен с тем, что эти приложения
должны иметь один набор бизнес-сущностей, иначе можно погрязнуть в
дублировании. Читаем у Фаулера:

Often you'll run into situations where different use cases work best
with different varieties of laziness. Some need one subset of the object
graph; others need another subset. For maximum efficiency you want to
load the right subgraph for the right use case.
The way to deal with this is to have separate database interaction
objects for the different use cases. Thus, if you use Data Mapper (165),
you may have two order mapper objects: one that loads the line items
immediately and one that loads them lazily. The application code chooses
the appropriate mapper depending on the use case. A variation on this is
to have the same basic loader object but defer to a strategy object to
decide the loading pattern. This is a bit more sophisticated, but it can
be a better way to factor behavior.

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

IT>>> Среди законов Мерфи есть один очень мудрый закон — закон Мейера "Усложнять — просто, упрощать — сложно".

MS>>Не только Мерфи принадлежит такая мысль. Ну да не об этом.

IT>Простите, Михаил, я вас забыл упомянуть

Забавно Вообще, посмотри в дополнение к высказываниям Эйнштейна (например, "Делай как можно проще, но не проще, чем нужно"). Много чего можно узнать. Например, прийдти к выводу, что высказывания популярных людей — есть аккумированная мудрость некоторых народов. А вообще фраза с подобным смыслом принадлежала еще какому-то русскому писателю. К сожалению, не помню его имя. И точно это был не Мерфи, так как тогда учился я в классе пятом (если еще не раньше).

На маппинг и прочее отвечу позднее (хотя явно идет процесс "толочь воду в ступе").

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

IT>Здравствуйте, Козьма Прутков, Вы писали:

КП>>ну, не скажи. Да, он требует, чтобы было подключение (а, возможно, и транзакция), с которого можно прочитать порцию данных. Но если коллекция (базовая) инкапсулирует в себе такую логику, почему бы и нет. Так например сделано в DevExpress Persistent Objects, есть там такая коллекция XPCursor. Не хочу сказать, что это хорошо, но вариант

IT>Я не против коллекции, я против того чтобы в таком виде она была частью объекта.

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

Например (схематично):

public class Product {

   int _key;
   private IDetailCollection _versions;

   public Product(int key) {
      _key = key;
      _versions = MyDb.Links.Product_Versions.GetDetail(_key);
   }

}

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

_>Если обобщить, то бизнес сущности должны максимально быть похоже на свой источник данных.

Зайди с другой стороны.
ПО — суть лишь модель происходящего. Ты выбираешь эту модель, уточняешь свои абстракции и т.д. Разумно ли в рамках одной системы городить несколько моделей, дублирующих друг-друга? И клиентские объекты, и серверные и их представление в БД должны быть максимально близки к модели приложения, тогда получишь меньше ненужных преобразований м/у моделями.

_>Никаким образом не должны пересекаться с DAL, не должны знать о своём происхождении.

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

_>Бизнес сущности должны быть самодостаточными, т.е недопустимо чтобы за какой-то порцией данных было обращение к DAL, интересно а как-же с lozy load?

Есть такой паттерн — прокси.

_>В моём случае получается, что функцию расчёта надо вынести из БО Company и перенести её в CompanyManager, который имеет отношение бизнес логике.

Речь идет о самодостаточности. От нее отталкивайся и принимай решения. Хотя, неплохим аргументом так же является некое единообразие элементов твоей модели. При прочих равных условиях идентичная организация элементов модели способствует дальнейшему сопровождению/изменению.

_>Правильно ли расматривать БО, как плоский объект, который должен иметь самую примитивную логику.
_>Каждый БО должен иметь объект БЛ который оперирует им (CompanyManager <---> Company)

Им могут оперировать несколько БЛ. Легче делить на сервисы. В принципе, ты можешь наделить некий выделенный БЛ объект ф-ю CRUD. Тогда сервисы будут представлять из себя объекты более высокого уровня. Я в своей модели вынес интерфейс IObjectStore для этих нужд (CRUD). В "простых" случаях (таких большинство) его реализует БЛ, который суть сервис для задач, связанных с БО (обычно с БО, который сам находится на вершине иерархии подчинения/владения)

_>Если у меня запрос состоит из нескольких таблиц, то как надо загружать БО? На каждую таблицу по БО или БО общий на запрос?

Желательно на каждый БО по таблице.
От чего отталкиваемся? База данных дана или мы ее разрабатываем? Если второе, то и карты в руки. При использовании объектных технологих надо макимально заточить БД на задачи персистенции объектов. Все.

Здравствуйте, Козьма Прутков, Вы писали:

КП>IT wrote:
>> Весьма распространённое и в то же время ошибочное мнение, которым обычно прикрывается либо кривой дизайн базы либо объектной модели. В процессе разработки модель данных и структура базы могу и должны соответствовать друг другу. Вот ты мне можешь привести живой хороший пример, когда различия в структуре базы и модели заложены в дизайне? Примеров замазывания дыр полно, но мне бы хотелось увидеть именно правильное решение, не by кривой design, а by прямой.
КП>ну например не будешь же ты связь БД много-на-много через промежуточную
КП>сущность отображать отдельным объектом? Не будешь.

Буду, и отображаю
ManyToManyLink у нас называется, объект заточен на предоставление сервисов выборки связанных объектов.


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

"Чужая база" — это действительно совершенно отдельный вопрос. Замечание IT насчет дыр и замазываний как раз лучше всего относится к такому случаю. Универсального решения этой проблемы нет. Решение надо вырабатывать на месте с учетом большого количества параметров (в общем случае).

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

IT>>Я не против коллекции, я против того чтобы в таком виде она была частью объекта.

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

А кто будет инициализировать этот фасад? К тому же надо будет на каждый тип коллекции создавать интерфейс :xz;

vdimas wrote:
> КП>IT wrote:
>>>Весьма распространённое и в то же время ошибочное мнение, которым обычно прикрывается либо кривой дизайн базы либо объектной модели. В процессе разработки модель данных и структура базы могу и должны соответствовать друг другу. Вот ты мне можешь привести живой хороший пример, когда различия в структуре базы и модели заложены в дизайне? Примеров замазывания дыр полно, но мне бы хотелось увидеть именно правильное решение, не by кривой design, а by прямой.
> КП>ну например не будешь же ты связь БД много-на-много через промежуточную
> КП>сущность отображать отдельным объектом? Не будешь.
> Буду, и отображаю
> ManyToManyLink у нас называется, объект заточен на предоставление сервисов выборки связанных объектов.
Ну, это вопрос реализации. Я бы, например, завел симметричные коллекции
у связанных объектов, аналогично как для связей 1:N частенько заводится
с одной стороны коллекция, а с другой — свойство (типа
заказ-коллекция_пунктов, пункт-заказ). Вот внутри — ради бога, пользуйся
чем угодно. Но в домене это понятие отсутствует, посему не надое его
навязывать.

> КП>Допустим, для оптимизации каких-нибудь отчетов ты денормализуешь схему,
> КП>что, и модель так же денормализовывать? Нет. Естественно, они будут
> КП>похожи, но не всегда один в один: представь, что ты уже имеешь чужую
> КП>базу и тебе надо на ней что-то построить. Я не думаю, что твоя модель
> КП>предметной области будет идентична наследию, ей богу
>
> "Чужая база" — это действительно совершенно отдельный вопрос. Замечание IT насчет дыр и замазываний как раз лучше всего относится к такому случаю. Универсального решения этой проблемы нет. Решение надо вырабатывать на месте с учетом большого количества параметров (в общем случае).

С тем, что это отдельный вопрос я нисколько не спорю. Надеюсь, с
утверждением о денормализации то ты согласен? Но по большому счету, если
уж тебе и надо вырасти на чужой базе, то скорее всего ты сделаешь
удобную себе модель, нежели создашь полное отображение того, что есть.
База данных — это средство хранения и получения информации. То, как ты
представляешь ее для работы приложения ну никак не обязано
соответствовать тому, как все это хранится. Типичный пример. Пусть есть
пара сущностей, между которыми есть логическая связь 1:N, но она
инициализируется крайне редко. Чтобы не расходовать место (в том числе в
индексах) вводится промежуточная сущность — связь (типа как для N:N,
только с некоторыми ограничениями, чтобы она работала только как 1:N).
Что, для нее тоже сущность заводить? Так это не соответствует модели
предметной области! Там не коллекция вторых сущностей, тем более не
странный ManyToManyLink, а именно ссылка одной сущности на другую. А как
это в БД — дело десятое.
Я могу согласиться в отношении соответствия с вами только в одном: на
начальных этапах разработки модель данных соответствует модели
предметной области, так уж процесс устроен, что сначала анализируется
домен (с его моделированием, результаты которого вырастают в модель
предметной области), а потом проектируется база. Но никак не наоборот.
Далее, по мере детализации проектирования, разработки и тем более
поддержки и развития эти модели расходятся.

Здравствуйте, Козьма Прутков, Вы писали:

КП>Я могу согласиться в отношении соответствия с вами только в одном: на
КП>начальных этапах разработки модель данных соответствует модели
КП>предметной области, так уж процесс устроен, что сначала анализируется
КП>домен (с его моделированием, результаты которого вырастают в модель
КП>предметной области), а потом проектируется база. Но никак не наоборот.
КП>Далее, по мере детализации проектирования, разработки и тем более
КП>поддержки и развития эти модели расходятся.

Ни в коем случае не расходятся, а уточняются детали имплементации. Модели не могут расходится. Если у нас в БД выделена отдельная таблица под хранения связей, а в коде нет соответствующей сущности, то ведь это не означает, что в приведенном тобой примере при изменении данных целевых сущностей (ссылка на 1 со стороны N) содержимое таблицы связей остается неизменным. Оно должно как-то синхронизироваться, либо через триггера, либо через открытие доступа к целевым таблицам посредством лишь SP. Т.е. налицо тонкости реализации, не более того. (точно так же, как данные одной сущности могут хранится в нескольких таблицах при отображении коллекции некой иерархии по наследованию... мне не нравится подобное отображение, но встречается регулярно)

Кстати, в моей модели у нас как отдельная сущность выступает и MasterDetailLink тоже
И предназначен именно для решения такого вопроса, как отделение связей м/у сущностями от способа представления этих связей в персинстентном блоке. Твой пример весьма удачен для моей модели.

Более того, я "агрессивно" занимаюсь кешированием данных, подобное отделение связей в отдельные сущности открывает мне широкий простор для повышения эффективности кеширования без значительных трудозатрат.

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

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

IT>>>Я не против коллекции, я против того чтобы в таком виде она была частью объекта.

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

IT>А кто будет инициализировать этот фасад?

Этот фасад инициаизирует внешний клиент связи. Он ее запрашивает у провайдера. Например, у меня так:

IDetailColelction MasterDetailLink.GetDetail(ObjectId key);

И что характерно, зачастую объект со стороны Master не запрашивает свой detail. Чаще всего его запрашивают адаптеры с GUI или адаптеры-деревья на стороне сервера.

Если же требуется выполнять какие-либо алгоритмы в самом БО со стороны Master, то ради бога — он запросит Detail для выбранной связи. Если эта штука не одноразового использования, я инкапсулирую в св-ва, т.е. проблем нет.

(по числу строк кода это не больше чем использование всяких Nhibernate или SPO, или еще каких, и гораздо проще, чем самому обслуживать подобные коллекции, где, кстати, неизбежно возникнет дублирование ссылок, или того хуже — объектов со стороны detail)


IT>К тому же надо будет на каждый тип коллекции создавать интерфейс :xz;

Пока юзаю обощенный интерфейс, потом перейду на генерики.

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

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

GZ>>Мне кажется, что тут у нас какая-то путаница в терминологии получилась. Поэтому я тебя и не понял. Может ты имел ввиду просто заполнение объекта?

IT>Да. Простое переливание из пустого в порожнее.
Все в мире относительно Если говорить о заполнении конкретного объекта, то да. А вот если говорить уже о коллекции, то не обязательно. Коллекция может состоять из инстансов объектов разных типов объединенными одним классом предка.
Или система из 1С(где-то Serginio1 описывал). Там строки хранятся по разбитые частям.

С уважением, Gleb.

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

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

GZ>>Два подхода:
GZ>>1. Сервер приложений глядит наверх некоторым интерфейсом с методами.
GZ>>например(пишу примерно):
GZ>>

GZ>>    public interface ILDDocumentInterface
GZ>>    {
GZ>>    //....
GZ>>        DataSet GetDocuments(object idJournal, object idRubric, string sort, string filter);
GZ>>    }
GZ>>

GZ>> Релизация
GZ>>

GZ>>    public class LDDocumentFacade:ILDDocumentInterface
GZ>>    {
GZ>>        DataSet GetDocuments(object idJournal, object idRubric, string sort, string filter);
GZ>>        {
GZ>>            Document[] documents=Registry.CreateDocuments(idJournal, idRubric, sort, filter);
GZ>>            return DTOAssembler.ParseToDTO(documents);
GZ>>        }
        
GZ>>    }
GZ>>

А>Есть маленький вопрос по этому примеру. Если предположим надо вернуть часть данных
А>из БО document, то где должна сидеть логика, что дать, а что нет. В DTOAssembler ?
Тут вопрос в том, зачем это нужно. Если это логика безопасности, то это отдельный механизм, который обычно реализуется как на уровне базы (вьюхи, хранимки, импесонализация (хотя и не очень приятный процесс), или просто добавление условий на select), так и на уровне бизнес логики (проверка могу ли я сохранить данный тип объекта). Однако я не советую делать безопасность на поля. Лучше разделить объекты.
Второй вопрос, если это нужно чтобы уменьшить оверхед трафика. В данном случае советую просто делать при переносе бизнес-объекта в формат DTO.

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

С уважением, Gleb.

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

_>Я не очень сильно вникал, но по моему, у всех етих продуктов, БО генерятся по таблицам. Т.е они максимально похоже на саму таблицу.
Нет. Это только один из способов. Бывает и класс-таблица. Иногда, если объект слишком большой, то его надо разбивать на разные таблицы (в силу ограничений размера на строку в БД), хотя такого я не слышал. Бывает система, когда строка текста разбивается на несколько строк (как это в 1С).

GZ>>Ну и третий, это то что xml формату на фиг сдались лишние поля. Есть они или нет, клиенту по фигу. Ему важно лишь то, чтобы там были именно его поля.

_>Не совсем так. То что можно видеть одному юзеру, то нельзя другому.
Это задача уже другого плана. Это задача безопасности, что есть отдельный механизм. Только что написал.Re[18]: Несколько вопросов по Меппарам.

Автор: GlebZ
Дата: 18.05.05

_>Что это за принцип достаточности функционала.
В разных источниках описывается по разному. Просто нужно делать только тот функционал, который достаточен для выполнения задачи на данной итерации разработки.

С уважением, Gleb.

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

А>>Есть маленький вопрос по этому примеру. Если предположим надо вернуть часть данных
А>>из БО document, то где должна сидеть логика, что дать, а что нет. В DTOAssembler ?
GZ>Тут вопрос в том, зачем это нужно. Если это логика безопасности, то это отдельный механизм, который обычно реализуется как на уровне базы (вьюхи, хранимки, импесонализация (хотя и не очень приятный процесс), или просто добавление условий на select), так и на уровне бизнес логики (проверка могу ли я сохранить данный тип объекта). Однако я не советую делать безопасность на поля. Лучше разделить объекты.
GZ>Второй вопрос, если это нужно чтобы уменьшить оверхед трафика. В данном случае советую просто делать при переносе бизнес-объекта в формат DTO.

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

GZ>С уважением, Gleb.

Дело не безопасности, а желании клиента.
Каждый клиент заинтересован в какой-то определенной информации.
Вот и получается, что одному надо все поля БО, а кому-то всего 2 поля.
Сейчас у меня есть следующая ситуация : есть БО Company, которая агрегирует CompanyFinancialDetailes. Мой меппер возвращает заполненный БО Company и CompanyFinancialDetailes(отношения у них 1-1). Есть юзер который хочет пару полей из БО Company и адреса. Адреса хранятся в отдельной таблице, значит надо составлять новый запрос под клиента с адресами. Т.е вариаций много, но как всё построить, что-бы не было неразберихи, какая функция меппара что подгружает.

А можно не много по-подробней о твоей реализации, ты описал всё на очень специфическом языке, я почти ничего не понял. Извините но я только новичёк.

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

А>А можно не много по-подробней о твоей реализации, ты описал всё на очень специфическом языке, я почти ничего не понял. Извините но я только новичёк.

В моем профайле мыло есть, могу кинуть часть доки с описанием.
Выкладывать сюда пока не могу по понятным причинам.

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

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

Я тебе поэтому и задавал наводящие вопросы типа можешь ли ты по записи определить тип объекта. Если да, то опять же, вопрос только в создании объекта правильного типа, а дальше обычный маппинг.

GZ>Или система из 1С(где-то Serginio1 описывал). Там строки хранятся по разбитые частям.

К сожалению, кривой дизайн ещё не считается преступление и Right Design Police Department не создан.

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

V>И что характерно, зачастую объект со стороны Master не запрашивает свой detail. Чаще всего его запрашивают адаптеры с GUI или адаптеры-деревья на стороне сервера.

Против этого возражений нет. Клиентский код как правило лучше всех знает что ему надо.

V>Если же требуется выполнять какие-либо алгоритмы в самом БО со стороны Master, то ради бога — он запросит Detail для выбранной связи. Если эта штука не одноразового использования, я инкапсулирую в св-ва, т.е. проблем нет.

Здесь я позволю себе возразить. В данном случае ты перенёс связь с источником данных из одного места объекта в другое, но эта связь всё равно осталась в объекте.

IT>>К тому же надо будет на каждый тип коллекции создавать интерфейс :xz;

V>Пока юзаю обощенный интерфейс, потом перейду на генерики.

Да уж... скорей бы

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

V>>Здесь я позволю себе возразить. В данном случае ты перенёс связь с источником данных из одного места объекта в другое, но эта связь всё равно осталась в объекте.

Ради бога, вопрос был в эффективности (GetDetail() — блокирующий метод), и в синтаксическом сахарке путем инкапсуляции повторного действия в проперти и запоминания результата.

V>>Пока юзаю обощенный интерфейс, потом перейду на генерики.

IT>Да уж... скорей бы

Microsoft подводит сильно. У нас релиз в середине лета, в конце прошлой осени я строил планы выпуска на 2.0
Придется толкать первую версию на 1.1

------
Как там с RFD, кстати?

Может пора начать переводить совместными усилиями на 2.0? Очень нада будет скоро , в долгу не останемся, свои надстройки выложу рядом.

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

V>Как там с RFD, кстати?

Я там кое что сломал, как только починю, так сразу выложу.

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

IT>Бизнес логике в БД вообще нечего делать. По многим причинам.
Угу. Есть только одна веская причина, по которой БЛ имеет смысл перетащить в БД: производительность на больших массивах. Но она находится в жёстком противоречии с гибкостью.

IT>DAL — это слой изолирующий базу данных от нашего приложения. Его задача — переводить термины базы данных в термины приложения. Т.е. из полей таблиц сконструировать объекты и наоборот. Опять же, никакой бизнес логики кроме конструирования объектов в нём быть не должно.
+1