С>2. Еще вариант по сабжу, да простит меня IT, и другие нелюбители DTO , но тут то он как раз ПОПУТНО решает данную проблему, т.е. BO мапится на DTO, с которым в свою очередь и работает DAL. Но подчеркиваю (во избежании флеймогона), что это всего лишь попутная задача решаемая DTO.
Простите друзья, а чем DTO отличается от Business Entity? Как я понимаю и то и другое dumb. Т.е. объект, который не содержит ничего кроме данных.
Так в чем между ними разница? Подозреваю что для одной BE много разных DTO?

Андрей.

AL>Простите друзья, а чем DTO отличается от Business Entity? Как я понимаю и то и другое dumb. Т.е. объект, который не содержит ничего кроме данных.
AL>Так в чем между ними разница? Подозреваю что для одной BE много разных DTO?
AL>Андрей.
УУУУ... лучше не обсуждать . Здесь: DTO внутри BusinessObject

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

С>Выносят, выносят..., и обычно это связано с нежеланием и не примиримостью архитектора развертывать код с обращением к БД на стороне клиента. Мотивируется обычно это соображениями безопасности, типа "нечего клиенту знать об объектах БД".
Ну, я то считал, что речь идет исключительно о серверном или исключительно о клиентском коде.
Серверный и клиентский DAL и BLL все равно сильно отличаются это и физически и логически разные компоненты. Что это за приложение такое, где DAL и BLL у клиента и сервера может быть общим и его надо искуственно выдирать?

С>Теперь о решении проблемы circular reference как таковой:
Сходу не разобрался, но слово Singletone напрягло, судя по всему дизайн довольно связный.. =) Потом еще помедитирую.

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

AL>Обращение к DAL.Order могут быть только из BLL.Order, больше нигде.
А сопутствующие классы, какие-нибудь хитрые описания заказа? У них свой отдельный DAL?

AL>Можешь привести пример, где нужен не прибитый гвоздями объект Order. Просто я пока с этим не сталкивался, но учитывать нужно.
Ну например клиенты захотят отслеживать изменения заказа через web-service. Ну или вы какого-нибудь удаленного SmartClient-а создать захотите.. Даже проще, просто через слои приложения сущности передавать.

AL>Вот у тебя тут получилось, что структура вышла плоская. Т.е. не смотря на то, что объекты разные, все лежит в одном классе на одном уровне. Теоретически, я не могу создать новый класс BabyPerson без перекомпиляции всей этой статической бизнес логики. И если бы лэто огически был наследник от, скажем, ProfessorPerson — тогда пришлось бы вызывать родительский метод вручную, хотя в C# уже есть на это дело инструменты ООП — virtual и override.
Тут выбирай... Но осторожно, но выбирай. Если у тебя добавление BabyPerson случается раз в пятилетку, то можно обойтисьи перекомпиляцией, все равно когда дело до добавления дойдет ты и не вспомнишь какую хитрую механику настраивал для удобства. А если задача регулярная (что сильно реже), тогда городи параллельную иерархию или еще как приседай.

AL>И чем ООП подход в этом случае не устроит.
Это и есть ООП. Или ты про наследование? Наследование вообще штука опасная, может боком выйти..

IB>Сходу не разобрался, но слово Singletone напрягло, судя по всему дизайн довольно связный.. =)
Singletone — это прокся у агента, агент ее инициализирует один раз.
Архитектура как раз получается гибкой, повыкидывать и переконфигурить можно практически всё. Единственное — вся работа происходит через прокси-классы, реализующие фасад-ин интерфейсы. Вообщем цепочки такие могут быть: агент->прокси->сервис->агент->прокси->DAL или агент->прокси->сервис->прокси->DAL или агент->прокси->DAL (в случае клиент-сервер).

AL>>Обращение к DAL.Order могут быть только из BLL.Order, больше нигде.
IB>А сопутствующие классы, какие-нибудь хитрые описания заказа? У них свой отдельный DAL?
Да, свой отдельный дал, свой префикс и таблицы. Т.к. фактически это другой объект. Например, нам нужен класс который содержит расширенную информацию по Order'у хранит некую логику по созданию репорта, создадим в этом случае объект OrderDescriber, сам Order трогать не будем, т.к. эта функциональность непосредственно к самому объекта не относится.

AL>>Можешь привести пример, где нужен не прибитый гвоздями объект Order. Просто я пока с этим не сталкивался, но учитывать нужно.
IB>Ну например клиенты захотят отслеживать изменения заказа через web-service. Ну или вы какого-нибудь удаленного SmartClient-а создать захотите.. Даже проще, просто через слои приложения сущности передавать.
А что мешает передать этот BLL.Order через web-service?

На счет между слоями вот ХЗ, не сталкивался пока, только BLL <> DAL.
Мне видится тут два варианта: 1. создавать объект-фасад и делать мэппинг 2. интерфейсы вытаскивать.
Зато в этом случае ты можешь опубликовать не весь объект, а только его часть, помимо этого, этим объектом можно будет загородить внутреннее хранение, именование, версионирование и даже логику.

AL>>И чем ООП подход в этом случае не устроит.
IB>Это и есть ООП. Или ты про наследование? Наследование вообще штука опасная, может боком выйти..
В BCL .NET'а практически все объекты хоть как-то участвуют в наследовании (помимо object ), и это же очень облегчает их понимание! На счет опасности, не знаю, смотря что под этим понимать.
Зато получается наглядно при меньшем объеме кода.

AL>>Простите друзья, а чем DTO отличается от Business Entity? Как я понимаю и то и другое dumb. Т.е. объект, который не содержит ничего кроме данных.
AL>>Так в чем между ними разница? Подозреваю что для одной BE много разных DTO?
AL>>Андрей.
С>УУУУ... лучше не обсуждать . Здесь: DTO внутри BusinessObject
Да, читал я эту увлекательную беседу. И так не понял в итоге чем Business Entity отличается от DTO. Оба dumb, в обоих хранится одна и то же — схема.
Понял из переписки что Игорь ярый противник DTO, но за Business Entity. А чем отличаются я так и не понял.

AL>Да, читал я эту увлекательную беседу. И так не понял в итоге чем Business Entity отличается от DTO. Оба dumb, в обоих хранится одна и то же — схема.
AL>Понял из переписки что Игорь ярый противник DTO, но за Business Entity. А чем отличаются я так и не понял.
Вообщем, попробую..., наверное, основной смысл который можно вынести из этого и не только этого обсуждения, это то, что DTO нужен для адаптации данных BO для передачи сторонним сервисам (свои обычно оперируют напрямую BO) и сокращения объема передаваемых данных. В этом случае DTO — это решение "влоб", плоский код, простой и понятный, не требующий разработки специфичной сериализации или схем сериализации. Обойтись без DTO конечно же можно (в .net благодаря гибким механизмам сериализации), и чаще всего это более правильно, но иногда он (DTO) помогает избежать некоторого тупика (идеалогического если хотите) и не выйти за пределы времени контрольных точек проекта.

С>1.Это создание прокси-классов, реализующих общий Facade-интерфейс.
С>Так существует ProxyDAL, ProxyService.
С>У меня примерно так: Клиент обращается к Agents, которые в зависимости от контекста выполнения приложения (клиент/сервер), инстанцируют тот или иной Singleton-Proxy (ProxyDAL, ProxyService). Какой прокси инстанцировать, задается в конфиге комбинацией IRemoteFacade+ProxyAssemblity+ProxyClass.
С>Proxy в свою очередь, уже напрямую, обращаются к DAL или к сервисам.
С>Может с небольшими кусочками примеров, чуть более ясно будет:
Эх... Задумываешься иногда, насколько все-таки разнообразный народ на белом свете живет.

Кто-то пишет хитрые прокси-классы. Кто-то, бизнес-логику на DataSet'ах и называет это best approach.
Другие глазом не моргнув из Business Entity обращаются к DAL'у. Четвертые пишут мегатурбофреймворки, один навороченнее другого. Пятые просто генерят мегабайты кода с помощью различных тулзов. Ну, а кто-то просто тупо копипастит.

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

AL>Фактически весь проект, со всеми слоями можно засунуть в одну сборку, В отдельных сборках только поместить расширения для системы — plugins.

Не исключено.

AL>Только нормально ли это если проект не маленький?

Ещё раз. Маленькость проекта не должна являться критерием разбиения проекта на сборки, т.к. здесь сложно выразить саму меру измерения. Какой ты хочешь получиь размер сборок? 128kb, 1M, 2Gb? Критерием может быть, например, деплоймент, или упомянутое Иваном желание получить гарантию независимости одного слоя от другого (т.к. это сложно получить с гарантнией другими способами), что-то ещё. Я, например, сталкивался с разделением сборок по тимам и даже девелоперам. Это всё имеет хоть какой-то смысл.

AL>Ну, в своем видении системы, я бы сделал это свойством определенно в одном классе Order, в этом случае, не приходилось бы думать содержит оно внутри логику для работы с БД или нет и где оно в OrderManager или в OrderInfo

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

IT>>И в чём проблема?
AL>Ну некрасиво как-то, нестройно

Видимо у нас разные критерии стройности. Мои критерии базируются из соображений сопровождаемости. Т.е. например, такую ерунду как obj.Save() vs. Save(obj) я легко приношу в жертву удобству сопровождения. Для меня качественная программа не та, которая правильно выглядит с точки зрения нравится/не нравится, а та, которая легко изменяется и при этом не теряет своих качеств к изменяемости. Такая своеобразная рекурсия. Если твой подход соответсвует этим критериям, то мы, как говоряю буржую, on the same page. Если нет, то скорее всего we are reading different books.

AL>>>Причина номер 3: наследование (см. ниже)
IT>>Наследование вполне можно использовать в объектной модели. Тоже не пойму проблему.
AL>Очень интересует, как можно метод сделать виртуальным (тот же Register)? Можно на примере кода, с которого я начинал тему.

AL>Я это обходил так, вводил параллельную иерархию и методы, работающие с самим экземпляром, делал нестатическими. Получалась параллельная иерархия вида
AL>PersonManager, ProfessorPersonManager : PersonManager, StudentPersonManager : PersonManager.
AL>И делал экземлярное поле private xxxPersonManager _info.

Я бы скорее всего завёл всего один manager.

AL>Вызывал методы примерно так: PersonManager.GetInstance(person).Register().
AL>В PersonManager.GetInstance в зависимости от типа person создавался соответствующий ему xxxPersonManager. Т.е. фактически, что можно было делать тремя классами приходилось делать шестью. И мне это очень не нравилось, как только я отошел от этой архитектуры, мне показалось что все стало на места.

Тут такое дело. Если у нас сильно разные объекты, то скорее всего нет смысла в наследовании, можно следать разные объекты. Если у нас сильно похожие объекты, то нет смысла в наследовании, можно сделать один объект.

AL>Не могу понять, почему бизнес логику и бизнес сущность нужно разделять? Для чего и в чем это помогает?

Всё просто. Это есть процесс отделения результата реализации чего-либо от самого процесса реализации. Бизнес логика весьма чувствительная к реализации вешь. Скажем так, это и есть сама реализация. Грубо говоря — BL есть хардкодинг бизнес правил. Бизнес сущность — это представление реализации, её следсвие, результат работы.

В результате, (простите за тафтологию) результат может быть использован независимо. Например, ГОСТ на подшибник, определяет сам подшибник, на не процесс его изготовления. Следовательно, такой подшибник может использоваться большинством производителей без привязки к тому, на каком станке был произведён данный подшибник. А раз нет привязки к станку, то есть возможность независимо развивать как сам станок, так и те процессы, которые используют результат работы данного станка.

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

AL>Да, читал я эту увлекательную беседу. И так не понял в итоге чем Business Entity отличается от DTO. Оба dumb, в обоих хранится одна и то же — схема.
AL>Понял из переписки что Игорь ярый противник DTO, но за Business Entity. А чем отличаются я так и не понял.

Проблема в том, что ты ищешь различия, а надо искать сходства. По большому счёту, BE это теже DTO, только без догм. Т.е. если часть логики может содержаться в BE, то нет никаих проблем.

C'est la vie

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

AL>Да, свой отдельный дал, свой префикс и таблицы. Т.к. фактически это другой объект. Например, нам нужен класс который содержит расширенную информацию по Order'у хранит некую логику по созданию репорта, создадим в этом случае объект OrderDescriber, сам Order трогать не будем, т.к. эта функциональность непосредственно к самому объекта не относится.
А если из соображений эффективности нужно делать джойны этих объектов на уровне БД, а не в выше?

AL>А что мешает передать этот BLL.Order через web-service?
И как ты его на клиенте использовать будешь, все же в методах...

AL>Мне видится тут два варианта: 1. создавать объект-фасад и делать мэппинг 2. интерфейсы вытаскивать.
AL>Зато в этом случае ты можешь опубликовать не весь объект, а только его часть, помимо этого, этим объектом можно будет загородить внутреннее хранение, именование, версионирование и даже логику.
То есть сделать DTO? А если в разных случаях потребуются разные части объекта — разные DTO? Ок, выделяем состояние объекта в один большой DTO и передаем его куда надо (по сути паттерн memento). Это приводит к тому, что у нас есть BL-class и State-class(наш DTO).
Теперь вся разница между твоим и моим подходом заключается в том, что у тебя BL-class обладает состоянием, а у меня нет. Но зачем возиться с состоянием BL-class-а, когда ничего не стоит этого не делать?

AL>В BCL .NET'а практически все объекты хоть как-то участвуют в наследовании (помимо object ), и это же очень облегчает их понимание!
Ага, а ты обратил внимание, что подавляющее большинство из них Sealed?

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

"alastochkin" <63963@users.rsdn.ru> wrote in message news:2386481@news.rsdn.ru...
> Добрый день, друзья.
>
> Помогите, пожалуйста, понять как решить проблему взаимодействия между DAL и BLL.
>
> Я использую custom entities (т.е. не DataSet'ы, а свои классы, см. пример кода ниже). Если я выделяю DAL в отдельную сборку, я не могу поместить ссылку на BLL, т.к. circular reference. Поэтому для того, чтобы я мог получить доступ из DAL к объектам бизнес логики мне нужно еще создать IPerson (куда вытащить все property Person, которые используются из DAL) и сделать Factory для Person, чтобы в DAL можно было создавать экземпляр Person.

Скажите, а зачем Вам из BLL ссылаться на DAL? отделите интерфейс маппинга от реализации.
BLL: Person
IDAL: IPersonMapper(Load, Save)
DAL: DbPersonMapper : IPersonMapper(Load, Save)

--
Илья