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

IT>>Если я закачиваю 1000 ордеров, то заполнение в каждом ордере коллекции айтемов увеличит объём данных в несколько раз, при том, что эта информация может оказаться абстолютно не нужной.

А>Так а что ж тогда не пойти по пути частичной загрузки этих самых айтемов? Одно большое множество. По мере надобности поступают элементы в него. А уж коллекции — это лишь частное преобразование на множество (Employess, FiredEmployess, ActiveEmployess и т.п.)

Против кеширования по мере необходимости никто не возражает.

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

Я хочу поблагодарить вас за ваше участие, для меня важно понять принципы и выроботать для себя определённые правила, поскольку с таким подходом почти не имел дело. У нас все работают по принципу transaction script и в самом плохом его смысле, где логика и доступ к данным перемешаны, так мы работали с VB, а на C# так работать не хочется. Прочитал Фаулера, думал будет понятней, а наоборот ещё больше запутался.

По поводу примера, который я привёл, то причиной переноса логики в базу данных, стала производительность.
Объём обрабатыбаемой информации зависит от самой фирмы, насколько она большая, есть компании у которых более 200 компаний, что сказывается на объём. Ещё добавлю, что изначально ты даже не знаешь сколько и какой тебе потребуется информации, ибо ето зависит от промежуточных данных. Промежуточный объём не большой, но частое обращение к базе данных сказывается. Етот модуль изначально был написан на клипере, потом на VB, а сейчас на T-SQL, разница в скорости изменилась на несколько порядков. Хотя лично я считаю, что ето не самый лучший выбор. Во первых Т-SQL, сам по себе бедный, сложность в отладке, и конечно не дай бог если наш заказчик захочет перейти на ORACLE.

Я пытаюсь для себя выработать определённые правила, но пока только получается или всё белое или чёрное.
В принципе мне нравится идея БО, которые ничего не должны знать о свём происхождении, не должны взимодействовать с источником данных, пока у меня не выробаталась своя точка зрения на то, как поступать с такого рода функциями, которые должны взаимодействовать с дополнительными источниками данными.
Я уже писал, что думаю её место в CompanyManager, который будет оперировать с БО Company, и всем другим что ему понадобится. Но считаю, что идея со стратегией тоже правильная, хотя мы добавляем дополнительную зависимость БО от стратегии, Может ету стратегию надо передать в CompanyManager, ето было бы более правильно.
У меня есть ещё парочка вопросов на которые я не знаю однозначного ответа :
1. Для каждого ли запроса надо создавать БО или использование датаридера ето преступление с точки зрения архитектуры.
2. Предположим у меня есть много разных запросов к таблице Company, но в каждом запросе используются разное количество полей етой таблицы, надо использовать БО Company частично заполненный или создавать разные вариации БО.
3. Уточню ранее заданый мной вопрос по поводу сложных запросов, я имел виду JOIN. При таком запросе надо создавать БО по каждой таблице или можно сделать один БО содержащий все поля.
4. Как лучше заполнять БО который имеет больше 20 полей, через свойства или конструктор, который имеет все поля.
5. Есть много разных проектов, в которых есть разные вариации поиска, предположим таблицы Company.
Ети запросы разбросаны по разным проектам, должны ли все запросы находится в одном CompanyMapper или ето нормально, что запросы разбросаны. Вот пример из жизни. Есть вебсервис который возвращает список фирм, етот список содержит только адреса и телефоны, где должен находится етот запрос в CompanyMapper или в каком-то модуле вебсервиса.
Есть вероятность того, что кто еще захочет использовать етот запрос и добавит что-то.И компания использующая вебсервис по ошибке получит больше информации чем ей хотят дать.

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

> мы добавляем дополнительную зависимость БО от стратегии, Может ету стратегию надо передать в CompanyManager, ето было бы более правильно.

ну, елки палки, я по-моему 2 раза написал, что БО зависит от ИНТЕРФЕЙСА
этой стратегии, определенном там же, где и БО. От него же зависит слой
данных, в котором присутствует реализация этого интерфейса. Так что
дополнительных зависимостей между слоями не добавляется.

> 1. Для каждого ли запроса надо создавать БО или использование датаридера ето преступление с точки зрения архитектуры.

я сейчас наблюдаю, как подрядчиком пишется приложение, которое выводит
список (результат поиска) путем загрузки коллекции БО. Это страшно
тормозит: вместо 1-го обращения к БД целых 80! И это только отладочные
данные, на несколько порядков меньшие по объему нежели рабочие. Так что
применить ридер с умом не считаю крамолой, вот только винформовый грид
им не умеет пользоваться

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

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

> 3. Уточню ранее заданый мной вопрос по поводу сложных запросов, я имел виду JOIN. При таком запросе надо создавать БО по каждой таблице или можно сделать один БО содержащий все поля.

по сути, соответсвующий таблице. Надо тебе подчиненный объект потрогать
— лезь к нему по ссылке (Order.Customer.Name, а не Order.CustomerName).

> 4. Как лучше заполнять БО который имеет больше 20 полей, через свойства или конструктор, который имеет все поля.

не готов ответить. Зависит от обстоятельств. Я бы сделал конструктор с
критическими данными (то есть обязательными), а остальное — через свойства.

> 5. Есть много разных проектов, в которых есть разные вариации поиска, предположим таблицы Company.
> Ети запросы разбросаны по разным проектам, должны ли все запросы находится в одном CompanyMapper или ето нормально, что запросы разбросаны. Вот пример из жизни. Есть вебсервис который возвращает список фирм, етот список содержит только адреса и телефоны, где должен находится етот запрос в CompanyMapper или в каком-то модуле вебсервиса.

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

> Есть вероятность того, что кто еще захочет использовать етот запрос и добавит что-то.И компания использующая вебсервис по ошибке получит больше информации чем ей хотят дать.

ну, брат, это описание интерфейса и не более того. Надо слать 2 поля —
один интерфейс, надо 5 — другой.

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

Это хорошо: высказывая свое мнение и споря об истине мы все набираемся
бесценного опыта. А поднятая тема весьма актуальна.

Хочу подчекнуть еще раз, что все написанное ИМХО и не претендует на
непреложную истинность.

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

_>У меня есть ещё парочка вопросов на которые я не знаю однозначного ответа :
_>1. Для каждого ли запроса надо создавать БО или использование датаридера ето преступление с точки зрения архитектуры.
Нельзя создавать на каждый запрос новый тип БО. У каждого БО есть некоторая описательная часть (пускай даже не физические метаданные, а в описании постановки). Для датасетов согласованность типов в основном достигается автоматическим добавлением схемы конкретного БО в общую схему и генерации части запросов (например полей select) через метаданные или вручную. Для entity, согласование с помощью DAL объектов, или с выделение общего механизма маппинга объектов на БЛ и автоматической генерации поисковых запросов.
_>2. Предположим у меня есть много разных запросов к таблице Company, но в каждом запросе используются разное количество полей етой таблицы, надо использовать БО Company частично заполненный или создавать разные вариации БО.
Опиши какую транзакционную систему ты будешь использовать. Это важно. Но скажу сразу, что нельзя один и те же данные использовать в разных бизнес-объектах. Причин много (от системы транзакций и согласования данных, до проблем с версионностью).
_>3. Уточню ранее заданый мной вопрос по поводу сложных запросов, я имел виду JOIN. При таком запросе надо создавать БО по каждой таблице или можно сделать один БО содержащий все поля.
БО в каждой таблице это наиболее простой путь. Но более эффективный путь когда структура бизнес-объекта никак не зависит от хранения. Вот тогда это также вопрос настройки производительности. При выделенном DAL ты спокойно можешь делать как тебе удобнее. Сама бизнес-логика от этого не пострадает. Тогда и таблицы можно рефакторить. А это уже очень большой плюс. И в зависимости от типа основного использования, ты можешь выбрать тот, или иной компромисс.
_>4. Как лучше заполнять БО который имеет больше 20 полей, через свойства или конструктор, который имеет все поля.
По фигу. Иногда даже есть смысл заполнять их через reflection.
_>5. Есть много разных проектов, в которых есть разные вариации поиска, предположим таблицы Company.
Выдели метаданные, и сделай единый поисковый механизм который работает во всех случаях.
_>Ети запросы разбросаны по разным проектам, должны ли все запросы находится в одном CompanyMapper или ето нормально, что запросы разбросаны. Вот пример из жизни. Есть вебсервис который возвращает список фирм, етот список содержит только адреса и телефоны, где должен находится етот запрос в CompanyMapper или в каком-то модуле вебсервиса.
_>Есть вероятность того, что кто еще захочет использовать етот запрос и добавит что-то.И компания использующая вебсервис по ошибке получит больше информации чем ей хотят дать.
Запросы не должны быть разбросаны, а лежать в едином DAL слое. Иначе система будет практически открытой и придется писать парсер запросов для обеспечения безопасности. Общение клиентов должно происходить через некоторый выделенные слой, в котором уже определяется кошерность клиента и достоен ли он его выполнить. Также на нем должна лежать задача уменьшения гранулярности запроса (возможно даже с помощью механизма запросов, а ля command паттерн). Но клиент ни в коем случае не должен знать не то, что про хранение, но и даже про бизнес-логику (неважно что это, некоторая сервисная модель, или объектная).
Что касается данного случая, то тут может быть два варианта. Вариант 1 — в каждом webservice находится компоненты представляющие данный бизнес-объект, которые уже общаются с БД. Вариант 2 — webservice обращается в единый центр, на котором и находится вся логика для данного бизнес объекта. Второй вариант значительно лучше.

Вообще, попробуй описать примерный механизм обеспечения транзакционности и согласованности данных который будет реализован. Тогда тебе многое станет более понятным.

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

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

IT>Весьма распространённое и в то же время ошибочное мнение, которым обычно прикрывается либо кривой дизайн базы либо объектной модели. В процессе разработки модель данных и структура базы могу и должны соответствовать друг другу. Вот ты мне можешь привести живой хороший пример, когда различия в структуре базы и модели заложены в дизайне? Примеров замазывания дыр полно, но мне бы хотелось увидеть именно правильное решение, не by кривой design, а by прямой.
До фигищи. Из последнего. Большинство объектов наследуется от класса типа MyObject где лежит некоторая системная информация. Для всех объектов в наследовании лучше работать без join, кроме данного MyObject, поскольку оказалось что большинство достаточно много частых важных запросов проходит только по MyObject. Вот и выделяем MyObject в отдельную таблицу. И это не замазывание дыр. Это просто настройка производительности работы БД. И скорость от такой нормализации и денормалиции возросла на некоторых процессах на порядки.

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

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

IT>Примеров замазывания дыр полно, но мне бы хотелось увидеть именно правильное решение, не by кривой design, а by прямой.

Если бы все было так просто, думается создатели RDBMS давно уже бы предоставили свое собственное решение, а не выдавали наружу интерфейс наподобии ExecuteScalar ExecureReader и т.п.

И еще. Маппер как раз для того и нужен, если структура сложная. При просто городить огород нечего.

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

GZ>До фигищи. Из последнего. Большинство объектов наследуется от класса типа MyObject где лежит некоторая системная информация. Для всех объектов в наследовании лучше работать без join, кроме данного MyObject, поскольку оказалось что большинство достаточно много частых важных запросов проходит только по MyObject. Вот и выделяем MyObject в отдельную таблицу. И это не замазывание дыр. Это просто настройка производительности работы БД. И скорость от такой нормализации и денормалиции возросла на некоторых процессах на порядки.

Информация о типе объекта как в базе хранится?

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

IT>>Примеров замазывания дыр полно, но мне бы хотелось увидеть именно правильное решение, не by кривой design, а by прямой.

MS>Если бы все было так просто,

Можно пример сложного?

MS> думается создатели RDBMS давно уже бы предоставили свое собственное решение, а не выдавали наружу интерфейс наподобии ExecuteScalar ExecureReader и т.п.

Для чего? Для UNIX, Windows, .NET, Java, C++? Или сразу для всего?

MS>И еще. Маппер как раз для того и нужен, если структура сложная. При просто городить огород нечего.

Mapper — это деталь имплементации, ничего более. Хелпер для DAL. Как ты думаешь, DAL вообще для чего нужен?

IT>Если я закачиваю 1000 ордеров, то заполнение в каждом ордере коллекции айтемов увеличит объём данных в несколько раз, при том, что эта информация может оказаться абстолютно не нужной.
Я применял для такого случая спциальную коллкцию позволяющею получать данные страницами.

UserCollection uс = firma.AllUser.LoadPage(3, 25);

LoadPage(номер страницы, колличество записей на странице)
Помимо этого можно было взять и всю коллекцию.

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

IT>Информация о типе объекта как в базе хранится?
В xml файле. Хранятся описания объектов — свойства, отношения наследования, ссылки и их отношения к БД. Тип в базе определяется либо по обязательным ссылкам (например обязательно должен быть связанные объект (класс потомок в объектой модели) в определенной таблице, либо по явному полю TypeID(в том числе и потому, что некоторые типы нельзя определить предыдущим способом).

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

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

Много написано, но всё равно для меня эти вещи абстрактные, нету до конца понимания, a что спросить не знаю. Тут наверное дело в опыте, пока сам не споткнёшся не поймёшь.
Может кто-нибудь знает какой-нибудь пример, что-бы можно было скачать и посмотреть,
на "правильную" архитектуру, желательно на C#.

_>>У меня есть ещё парочка вопросов на которые я не знаю однозначного ответа :
_>>1. Для каждого ли запроса надо создавать БО или использование датаридера ето преступление с точки зрения архитектуры.
GZ>Нельзя создавать на каждый запрос новый тип БО. У каждого БО есть некоторая описательная часть (пускай даже не физические метаданные, а в описании постановки). Для датасетов согласованность типов в основном достигается автоматическим добавлением схемы конкретного БО в общую схему и генерации части запросов (например полей select) через метаданные или вручную. Для entity, согласование с помощью DAL объектов, или с выделение общего механизма маппинга объектов на БЛ и автоматической генерации поисковых запросов.


Как быть в случаях, когда БО в разных проектах могут иметь разную форму.
Есть проект администрации (интранет), где всё идёт через XML. У нас есть своя библиотека, которая генерит ХМЛ из запроса в определённом формате, этот xml поступает на html клиент, где этим хмл бандятся контроли, тоже разработанные на нашей фирме( очень много javascript ), потом для сохранения генерится общий ХМЛ,
содержащий старую запись и измененную, забрасывается на сервер и при помощи той-же библиотеки меппируется на таблицы. Есть другой проект интернет, где по политическим соображениям не используют нашу замечательную библиотеку и там ты должен работать с теми-же таблицами, не ипользуя ХМЛ, и не очень хочется использовать dataset, а значит ты должен использовать БО как классы, вот и получаются различии. Правильно ли называть ХМЛ содержащий данные из базы данных БО или это уже DTO.



_>>2. Предположим у меня есть много разных запросов к таблице Company, но в каждом запросе используются разное количество полей етой таблицы, надо использовать БО Company частично заполненный или создавать разные вариации БО.
GZ>Опиши какую транзакционную систему ты будешь использовать.

Что Вы имете ввиду.

GZ>Это важно. Но скажу сразу, что нельзя один и те же данные использовать в разных бизнес-объектах. Причин много (от GZ>системы транзакций и согласования данных, до проблем с версионностью).
_>>3. Уточню ранее заданый мной вопрос по поводу сложных запросов, я имел виду JOIN. При таком запросе надо создавать БО по каждой таблице или можно сделать один БО содержащий все поля.
GZ>БО в каждой таблице это наиболее простой путь. Но более эффективный путь когда структура бизнес-объекта никак не зависит от хранения. Вот тогда это также вопрос настройки производительности. При выделенном DAL ты спокойно можешь делать как тебе удобнее. Сама бизнес-логика от этого не пострадает. Тогда и таблицы можно рефакторить. А это уже очень большой плюс. И в зависимости от типа основного использования, ты можешь выбрать тот, или иной компромисс.


Согласен, что предназначение меппара, как раз и состоит в абстрагировании между БО и источником данных, но чем больше они похоже, тем проще DAL слой. Наверное различая появляются, только при довольно сложной логике и связях, но в большинстве они могут быть очень похоже, хотя всё зависит от нагрузки которую несёт БО.
Предположим если меняется структура в базе данных, есть дилемма, поменять ДАЛ слой не трогая БО, или поменять БО, что более логичней, при етом ты должен сделать рефакторинг всего своего кода, где он применяется. Но знаете иногда, когда смотришь на код, где-то через годик, ты уже не помнишь почему у тебя структура БО и базы данных разная, а DAL так извращается что-бы наложить БО на базу данных.


_>>4. Как лучше заполнять БО который имеет больше 20 полей, через свойства или конструктор, который имеет все поля.
GZ>По фигу. Иногда даже есть смысл заполнять их через reflection.


Reflection это интересная тема, тут главное правильно поставить вопрос : в каких случаях её надо применять из-за производительности или в каких случаях её не надо применять,может не так чёрт страшен, как его рисуют.

_>>5. Есть много разных проектов, в которых есть разные вариации поиска, предположим таблицы Company.
GZ>Выдели метаданные, и сделай единый поисковый механизм который работает во всех случаях.

А как эти слова преобразовать в код?


_>>Ети запросы разбросаны по разным проектам, должны ли все запросы находится в одном CompanyMapper или ето нормально, что запросы разбросаны. Вот пример из жизни. Есть вебсервис который возвращает список фирм, етот список содержит только адреса и телефоны, где должен находится етот запрос в CompanyMapper или в каком-то модуле вебсервиса.
_>>Есть вероятность того, что кто еще захочет использовать етот запрос и добавит что-то.И компания использующая вебсервис по ошибке получит больше информации чем ей хотят дать.
GZ>Запросы не должны быть разбросаны, а лежать в едином DAL слое. Иначе система будет практически открытой и придется писать парсер запросов для обеспечения безопасности.

Что такое парсер запросов в этом контексте?

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

Написано хорошо, как это преобразовать в код не совсем понимаю.
Извините за не компетентность. Я не то что не умею писать классы, просто эти слова у меня не ассоциируются с чем-то реальным, абстракция.



GZ>Что касается данного случая, то тут может быть два варианта. Вариант 1 — в каждом webservice находится компоненты представляющие данный бизнес-объект, которые уже общаются с БД. Вариант 2 — webservice обращается в единый центр, на котором и находится вся логика для данного бизнес объекта. Второй вариант значительно лучше.


Это значит, что у меня есть отдельный общий проект, где хранятся все меппары или DAL объекты( как кому нравится ), в CompanyMapper будет функция GetCompanyForWebService(), GetCompanyForAdminSite(), GetCompanyForWebSite(),
GetCompanyForBatch() ....
Что-то вроде этого?




GZ>Вообще, попробуй описать примерный механизм обеспечения транзакционности и согласованности данных который будет реализован. Тогда тебе многое станет более понятным.

Можно по подробней, что вы имеете ввиду?

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

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

>> мы добавляем дополнительную зависимость БО от стратегии, Может ету стратегию надо передать в CompanyManager, ето было бы более правильно.

КП>ну, елки палки, я по-моему 2 раза написал, что БО зависит от ИНТЕРФЕЙСА
КП>этой стратегии, определенном там же, где и БО. От него же зависит слой
КП>данных, в котором присутствует реализация этого интерфейса. Так что
КП>дополнительных зависимостей между слоями не добавляется.

>> 1. Для каждого ли запроса надо создавать БО или использование датаридера ето преступление с точки зрения архитектуры.

КП>я сейчас наблюдаю, как подрядчиком пишется приложение, которое выводит
КП>список (результат поиска) путем загрузки коллекции БО. Это страшно
КП>тормозит: вместо 1-го обращения к БД целых 80!
КП>И это только отладочные



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


А можно как сформировать ввиде каких-то общих правил, когда применять, а когда не применять.


>> 5. Есть много разных проектов, в которых есть разные вариации поиска, предположим таблицы Company.
>> Ети запросы разбросаны по разным проектам, должны ли все запросы находится в одном CompanyMapper или ето нормально, что запросы разбросаны. Вот пример из жизни. Есть вебсервис который возвращает список фирм, етот список содержит только адреса и телефоны, где должен находится етот запрос в CompanyMapper или в каком-то модуле вебсервиса.

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

>> Есть вероятность того, что кто еще захочет использовать етот запрос и добавит что-то.И компания использующая вебсервис по ошибке получит больше информации чем ей хотят дать.

КП>ну, брат, это описание интерфейса и не более того. Надо слать 2 поля —
КП>один интерфейс, надо 5 — другой.


А можно примерчик

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

QET>Я применял для такого случая спциальную коллкцию позволяющею получать данные страницами.

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

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

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

QET>>Я применял для такого случая спциальную коллкцию позволяющею получать данные страницами.

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

Из чего такое следует?

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

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

А>Из чего такое следует?

LoadPage откуда данные берёт?

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

_>Может кто-нибудь знает какой-нибудь пример, что-бы можно было скачать и посмотреть,
_>на "правильную" архитектуру, желательно на C#.
А никто и не скажет, что такое "правильная" архитектура. Архитектура очень зависит от конкретного решения. Существует несколько шаблонов по которым строятся многозвенные и распределенные приложения. Все остальное творчество, или использование готовых решений.

_>Как быть в случаях, когда БО в разных проектах могут иметь разную форму.
_>Есть проект администрации (интранет), где всё идёт через XML. У нас есть своя библиотека, которая генерит ХМЛ из запроса в определённом формате, этот xml поступает на html клиент, где этим хмл бандятся контроли, тоже разработанные на нашей фирме( очень много javascript ), потом для сохранения генерится общий ХМЛ,
_>содержащий старую запись и измененную, забрасывается на сервер и при помощи той-же библиотеки меппируется на таблицы. Есть другой проект интернет, где по политическим соображениям не используют нашу замечательную библиотеку и там ты должен работать с теми-же таблицами, не ипользуя ХМЛ, и не очень хочется использовать dataset, а значит ты должен использовать БО как классы, вот и получаются различии. Правильно ли называть ХМЛ содержащий данные из базы данных БО или это уже DTO.
Это DTO. Всего лишь протокол обмена данными между сервером и клиентами. После прихода данных, из них уже формируются реальные бизнес-объекты. Таким образом, бизнес логика не зависит от клиента, и сервер приложений может работать с несколькими типов протоколов обмена не изменяя бизнес логику.

_>Согласен, что предназначение меппара, как раз и состоит в абстрагировании между БО и источником данных, но чем больше они похоже, тем проще DAL слой. Наверное различая появляются, только при довольно сложной логике и связях, но в большинстве они могут быть очень похоже, хотя всё зависит от нагрузки которую несёт БО.
_>Предположим если меняется структура в базе данных, есть дилемма, поменять ДАЛ слой не трогая БО, или поменять БО, что более логичней, при етом ты должен сделать рефакторинг всего своего кода, где он применяется. Но знаете иногда, когда смотришь на код, где-то через годик, ты уже не помнишь почему у тебя структура БО и базы данных разная, а DAL так извращается что-бы наложить БО на базу данных.
Проясню. Полная независимость в принципе бывает только в сказке. Но! Все изменения связанные с хранилищем бывают двух видов:
1. Изменение связанные с изменениями в логике работы приложения. Тогда изменения(в большинстве случаев) идут вертикально по всем слоям.
2. Изменения связанные с улучшениями характеристик приложения. Вот тут, сколько не изменяй, любой нормальный базовед сразу скажет что где и как вяжется. Процесс нормализации-денормализации отнюдь не изменяют сами свойства системы. Они просто адаптируют хранилище для более эффективного использования. А реляционная модель достаточно архаична и ее связь с объектной моделью всегда легко понять.

_>Reflection это интересная тема, тут главное правильно поставить вопрос : в каких случаях её надо применять из-за производительности или в каких случаях её не надо применять,может не так чёрт страшен, как его рисуют.
Дело в том, что на фоне работы с базой данных падение производительности практически незаметны. Поэтому, это всего лишь вопрос удобства.

_>>>5. Есть много разных проектов, в которых есть разные вариации поиска, предположим таблицы Company.
GZ>>Выдели метаданные, и сделай единый поисковый механизм который работает во всех случаях.
_>А как эти слова преобразовать в код?
По всей структуре данных, строятся метаданные (свойства, ссылки и их типы). По этим метаданным выделяется строка запроса в базу данных.
Советую посмотреть (или лучше воспользоваться) готовыми ORM решениями типа Hibernate(NHibernate). Существует также огромное количество коммерческих решений (DataObjects, Versant).

GZ>>Запросы не должны быть разбросаны, а лежать в едином DAL слое. Иначе система будет практически открытой и придется писать парсер запросов для обеспечения безопасности.
_>Что такое парсер запросов в этом контексте?
Насколько я понял твое сообщение, вы пересылаете SQL запрос с клиента. Так делать нельзя. Точнее можно, но при этом надо проверять саму SQL строку на момент того, что злоумышленники дописали ее чтобы получить чужие данные.

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

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

Релизация

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

Таким образом, клиент даже не знает о существовании документа. Он видит только интерфейс предоставленный сервером приложений и DTO который получит как результат.
2. Запросы типа Command. На сервер передается коммандная строка (или набор командных объектов) , которые на сервере распарсиваются и преобразуются в команды выполняемые сервером приложений. Удобный (но достаточно сложный) механизм для работы сразу с пакетом команд в рамках одного запроса.

_>GZ>>Что касается данного случая, то тут может быть два варианта. Вариант 1 — в каждом webservice находится компоненты представляющие данный бизнес-объект, которые уже общаются с БД. Вариант 2 — webservice обращается в единый центр, на котором и находится вся логика для данного бизнес объекта. Второй вариант значительно лучше.

_>Это значит, что у меня есть отдельный общий проект, где хранятся все меппары или DAL объекты( как кому нравится ), в CompanyMapper будет функция GetCompanyForWebService(), GetCompanyForAdminSite(), GetCompanyForWebSite(),
_>GetCompanyForBatch() ....
_>Что-то вроде этого?
Немного не понял что ты имеешь ввиду. У сервиса должен быть процесс идентификации пользователя в котором он определяет какие объекты и бизнес логику имеет права задействовать тот, или иной пользователь. Система прав едина для всей системы. И в зависимости от прав конкретного пользователя, можно как задействовать процессы бизнес логики(см Principals если мы говорим о Net), и определенные бизнес объекты (которые действительно могут отсекаться на уровне Mappers или(и) вообще на уровне запросов к хранилищу).
Бизнес логика на сервере приложений работают только с одним видом бизнес объектов. А вот предоставление результатов(что касается первого твоего вопроса про DTO), можно делать на любом протоколе. Например, в примерном коде (тот что наверху) можно сделать так, что DTOAssembler будет создавать DTO по объектам в зависимости от типа клиента (точнее протокола по которому клиент работает). Или можно сделать для каждого вида клиента, свой Remoting Facade. Но бизнес логика при этом остается независимой от клиента. И о мапперах, клиент тем более не знает.

GZ>>Вообще, попробуй описать примерный механизм обеспечения транзакционности и согласованности данных который будет реализован. Тогда тебе многое станет более понятным.

_>Можно по подробней, что вы имеете ввиду?
Оптимистические пессимистические транзакции. Типы блокировок — жесткие, нежесткие. Всемя жизни бизнес транзакции (один запрос, несколько запросов). Механизм согласованности данных(Unit of work и Identity Map в терминах Фаулера).
За терминологией — Фаулер и например:здесьЗдесь перевод. Еще можешь это Re: Транзакции

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

посмотреть.

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

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

IT>>>Примеров замазывания дыр полно, но мне бы хотелось увидеть именно правильное решение, не by кривой design, а by прямой.

MS>>Если бы все было так просто,

IT>Можно пример сложного?

MS>> думается создатели RDBMS давно уже бы предоставили свое собственное решение, а не выдавали наружу интерфейс наподобии ExecuteScalar ExecureReader и т.п.

IT>Для чего? Для UNIX, Windows, .NET, Java, C++? Или сразу для всего?

Универсальных инструментов не существует. Гоняться за ними — себе дороже. Это лирическое отступление. Насчет того, как бы развивались RDBMS, то Sql Server пощел бы по линейке .NET + Windows. Собственно, он уже это сделал. Oracle — по своей (Java). Для С++ нужно лишь сделать выбор (.NET или не .NET).

MS>>И еще. Маппер как раз для того и нужен, если структура сложная. При просто городить огород нечего.

IT>Mapper — это деталь имплементации, ничего более.

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

IT>Хелпер для DAL.

Если в общем случае — то не правильно. Если в контексте RFD, то возможно.

IT>Как ты думаешь, DAL вообще для чего нужен?

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

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

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

GZ>В xml файле. Хранятся описания объектов — свойства, отношения наследования, ссылки и их отношения к БД. Тип в базе определяется либо по обязательным ссылкам (например обязательно должен быть связанные объект (класс потомок в объектой модели) в определенной таблице, либо по явному полю TypeID(в том числе и потому, что некоторые типы нельзя определить предыдущим способом).

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

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

GZ>>В xml файле. Хранятся описания объектов — свойства, отношения наследования, ссылки и их отношения к БД. Тип в базе определяется либо по обязательным ссылкам (например обязательно должен быть связанные объект (класс потомок в объектой модели) в определенной таблице, либо по явному полю TypeID(в том числе и потому, что некоторые типы нельзя определить предыдущим способом).

IT>Т.е. на начала процесса маппинга мы можем узнать какой бизнес объект конструировать и какие правила маппинга применять? Так?
Не понял. Вот вам void*, вот вам схема dbo, теперь хочу коммунизм?
IT>Т.е. усложнение самого процесса у нас только в этом месте, сам же маппинг может оставаться таким же простым. Т.е. мимо пока мимо кассы. Ещё варианты будут?
Теперь я уже в полных непонятках. Что ты имеешь ввиду под усложнением процесса при том что маппинг является простым?

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

QET>>Я применял для такого случая спциальную коллкцию позволяющею получать данные страницами.
IT>Не использовать подобный подход мы договорились в самом начале топика. Это намертво гвоздями прибивает твою бизнес сущность к источнику данных.

Но у меня всегда один тип данных, это база данных. В качестве хранилища файлы не используются.
Для доступа к данным у меня используется DAL. У каждой BEntity есть свой класc DAL`a. Задача при построении коллекции правильно задать критерии DAL`у ,а он уже сам генерирует SQL запрос.