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

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

igor_fle wrote:
>>>Есть вероятность того, что кто еще захочет использовать етот запрос и добавит что-то.И компания использующая вебсервис по ошибке получит больше информации чем ей хотят дать.
> КП>ну, брат, это описание интерфейса и не более того. Надо слать 2 поля —
> КП>один интерфейс, надо 5 — другой.
> А можно примерчик

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

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

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

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

Это понятно, что никто не скажет, что такое правильная архитектура,
но всегда полезно посмотреть на разные примеры "правильной" реализации для конкретного случая.

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

Да, вот этого слоя у нас как раз и нету.
У нас DTO --> БД, при этом у нас нет заморочек с БО, бросил ХМЛ и никакой головной боли, хотя я и не говорю, что это правильно.



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


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


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


Да нет, я совсем не это имел ввиду, никто SQL запрос не передаёт.
Просто на данный момент у нас не существует слоя БО, есть разные проэкты с различными вариациями запросов к одним и тем-же таблицам, которые возвращают datareader или dataset. Вопрос стоит в том, стоит ли их всех объединить в один общий проект или нет. Если же их соеденить, то есть вероятность, что программист Вася решил, что запрос, кторый написал Вова для вебсервиса, ему тоже подходит, но вот только он добавит пару полей, при етом вебсервис который сделал Вова начнёт возвращать не множко больше данных, чем надо.


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

Всё красиво, вот только я не найду достаточно веских аргументов на работе, что бы всех убедить, зачем я строю сначала БО документы, а потом ими заполняю dataset, ведь можно сразу это сделать


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

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

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


Твой пример снял этот вопрос.

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

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

КП>igor_fle wrote:
>>>>Есть вероятность того, что кто еще захочет использовать етот запрос и добавит что-то.И компания использующая вебсервис по ошибке получит больше информации чем ей хотят дать.
>> КП>ну, брат, это описание интерфейса и не более того. Надо слать 2 поля —
>> КП>один интерфейс, надо 5 — другой.
>> А можно примерчик

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

Реализации этих интерфейсов будут, обращатся к DAL слою который, мне вернёт БО Company, и заполнит им какой-то DTO необходимой информацией, при етом каждый берёт свою порцию информации, значит мне надо любой БО всегда заполнять всеми полями из таблицы, что мне очень нравится, но ведь для каждого случая надо разное количество информации, а если будет сложный запрос с коллекциями, то это убъёт производительность.

igor_fle wrote:
> Здравствуйте, Козьма Прутков, Вы писали:
> Реализации этих интерфейсов будут, обращатся к DAL слою который, мне вернёт БО Company, и заполнит им какой-то DTO необходимой информацией, при етом каждый берёт свою порцию информации, значит мне надо любой БО всегда заполнять всеми полями из таблицы, что мне очень нравится, но ведь для каждого случая надо разное количество информации, а если будет сложный запрос с коллекциями, то это убъёт производительность.
это уже из разряда "и на елку влезть и попу не поцарапать"
никто же не говорит о том, что по запросу на загрузку кастомера надо
тащить в память полбазы? Ну, загрузил часть реально нужных коллекций, а
остальное — lazy. Хотя, тут всем не угодишь, компромисс треба.
Если так важна производительность и на использовании этих средств она
неприемлемо провисает, то флаг в руки, грузи кусок данных другими путями
(это никто не запрещает) и передавай, деваться некуда. Менять данные так
не стоит, иначе получишь неизвестно-как-работающее месево.

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

КП>это уже из разряда "и на елку влезть и попу не поцарапать"
КП>никто же не говорит о том, что по запросу на загрузку кастомера надо
КП>тащить в память полбазы? Ну, загрузил часть реально нужных коллекций, а
КП>остальное — lazy. Хотя, тут всем не угодишь, компромисс треба.
КП>Если так важна производительность и на использовании этих средств она
КП>неприемлемо провисает, то флаг в руки, грузи кусок данных другими путями
КП>(это никто не запрещает) и передавай, деваться некуда. Менять данные так
КП>не стоит, иначе получишь неизвестно-как-работающее месево.

Я не говорю, что-бы пол базы данных вытащить. Мы подходим к кастомизации DAL слоя, в зависимости от использования, для одной аппликации мне надо первых 20 полей таблицы, для второй мне другие нужны 20, а для 3 надо только одно поле, при сложных запросах комбинации возрастают, как в этих случаях правильно поступить?

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

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

_>Да, вот этого слоя у нас как раз и нету.
_>У нас DTO --> БД, при этом у нас нет заморочек с БО, бросил ХМЛ и никакой головной боли, хотя я и не говорю, что это правильно.
Иногда это правильно. Особенно, когда на сервере практически нет бизнес-логики. Правда не в вышеописанном случае. В данном случае, выделенный Remote Facade и DTO обязательны.

GZ>>По всей структуре данных, строятся метаданные (свойства, ссылки и их типы). По этим метаданным выделяется строка запроса в базу данных.
GZ>>Советую посмотреть (или лучше воспользоваться) готовыми ORM решениями типа Hibernate(NHibernate). Существует также огромное количество коммерческих решений (DataObjects, Versant).
_>Что мне не нравится в подобных продуктах, что они навязывают свой стиль работы, мне больше нравятся продукты, похожие на РФД, он больше хелпер, чем чёрный ящик.
Потому что его функциональность достаточно невелика, поэтому кажется что он простой. Что касается стиля работы, то не забывай что это правильный стиль работы проверенный на реальных приложениях. Делать те же самые вещи самому, нужно угрохать достаточно много времени на постановку и продумывание + достаточные знания.

_>Да нет, я совсем не это имел ввиду, никто SQL запрос не передаёт.
_>Просто на данный момент у нас не существует слоя БО, есть разные проэкты с различными вариациями запросов к одним и тем-же таблицам, которые возвращают datareader или dataset. Вопрос стоит в том, стоит ли их всех объединить в один общий проект или нет.
Соединить, и не плодить практически одинаковый код всегда стоит. Невыполнение этого условия платится повышенными затратами на разработку и сопровождение. Две — три реализации и синхронизация их работы очень неприятная вещь ведущая к большим затратам.

_>Если же их соеденить, то есть вероятность, что программист Вася решил, что запрос, кторый написал Вова для вебсервиса, ему тоже подходит, но вот только он добавит пару полей, при етом вебсервис который сделал Вова начнёт возвращать не множко больше данных, чем надо.
Могу предложить два способа. Первый способ, версионификация интерфейсов. Программист Вася написал клиента под интерфейс 1.1. Программисту Коле потом не хватило интерфейса 1.1 и он решил создать интерфейс 1.2 с измененными параметрами вызова. В результате, внутри сервера приложений, он изменил логику так, чтобы она работала как с интерфейсом 1.1, так и с интерфейсом 1.2.(обычно это легко проходит). И как бы, все остались при своем. В зависимости от заказанного интерфейса — бизнес-логика адаптируется под него. А чаще всего даже интерфейс 1.2 содержит(наследует) интерфейс 1.1 как свое подмножество.
Второй способ, введение как параметра функции — список полей которые хочется получить в том, или ином случае. Но я бы сказал это полумера которая была бы хороша в дополнение к первому способу. Чтобы плодить меньше версий. Ессно, если бизнес-объекты в данном виде используются только на сервере.
Ну и третий, это то что xml формату на фиг сдались лишние поля. Есть они или нет, клиенту по фигу. Ему важно лишь то, чтобы там были именно его поля.

_>Всё красиво, вот только я не найду достаточно веских аргументов на работе, что бы всех убедить, зачем я строю сначала БО документы, а потом ими заполняю dataset, ведь можно сразу это сделать
Можно. Любое решение должно быть достаточным. Аргументация может быть такой. Для сложных систем при реализации в схеме без явного разделения на слои, и в том числе на слой независимости от клиента, затраты на разработку новой функциональности и сопровождение растет экспотенциально. Но не забудь, что именно для сложных систем. Для простых существует принцип достаточности функционала.

_>Твой пример снял этот вопрос.

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

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

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

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

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

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

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

Мда... void* — это мрачно. Ты хочешь сказать, что ты без понятия какой объект собираешься конструировать?

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

Усложняется процесс создания объекта, т.е. по данным из рекордсета ты должен определить какого типа объект создавать. Но сам мапинг после этого остаётся таким же.

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

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

MS>Универсальных инструментов не существует....

[лирические отступления поскипаны]

Ты мне так и не дал пример сложного.

MS>>>И еще. Маппер как раз для того и нужен, если структура сложная. При просто городить огород нечего.
IT>>Mapper — это деталь имплементации, ничего более.
MS>Утверждение настолько размыто, что ни согласиться, ни опровергнуть я не могу. Перефразируй данное высказывание, пожалуйста.
IT>>Хелпер для DAL.
MS>Если в общем случае — то не правильно. Если в контексте RFD, то возможно.

При чём тут RFD? Мы говорим о маппинге в контексте топика. Автор топика может вообще будет делать маппинг ручками.

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

MS>Лучше я скажу, в чем я не согласен в твоих высказываниях.

Опять ты уходишь от вопроса.

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

Точно. При правильной архитектуре всё должно быть просто.

MS>В простых системах это и так.

Можешь дать нам определение "простой системы", а заодно и "сложной"?

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

Если бы ты знал для чего нужен DAL, то и с интеграцией у тебя было бы меньше проблем

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

У меня есть подозрение, что ты путаешь понятия мапинг и ORM. Это не совсем одно и тоже.

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

Что значит "маппинг должен быть настраиваемым"? Настраиваемым кем, пользователем или программистом? Поясни пожалуйста.

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

IT>Усложняется процесс создания объекта, т.е. по данным из рекордсета ты должен определить какого типа объект создавать. Но сам мапинг после этого остаётся таким же.
Не только по данным рекордсета, но и по метаданным и самому объектному запросу. У меня значительно все сложней. Маппер один и содержит в себе все метаданные. Существует механизм — некоторая поисковая машина. Поисковая машина работает по некоторому объектному запросу. Она берет этот объектный запрос, формирует из него SQL, создает объекты и заполняет их и их связи. Самое вкусное и интересное, система наследования. Дело в том, что родители могут лежать как в специальном классе-таблице, так и в таблице потомка. Объектный запрос и сам объект об этом даже не догадывается, все реализуется в самом едином маппере. И в объектном запросе, можно спокойно заказать некоторые абстрактные классы, которые вернуться инстанцирумыми потомками. SQL запросов при этом получается больше одного. И собственно как создание объекта, формирование и выполнение SQL запросов, заполнение объекта — это один сильно связанный механизм. Впрочем, в Фаулере, насколько я помню, мапперы также занимались именно этими вещами. Мне кажется, что тут у нас какая-то путаница в терминологии получилась. Поэтому я тебя и не понял. Может ты имел ввиду просто заполнение объекта?

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

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

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

Да. Простое переливание из пустого в порожнее.

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

MS>>Универсальных инструментов не существует....

IT>[лирические отступления поскипаны]

IT>Ты мне так и не дал пример сложного.

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

IT>>>Хелпер для DAL.
MS>>Если в общем случае — то не правильно. Если в контексте RFD, то возможно.

IT>При чём тут RFD? Мы говорим о маппинге в контексте топика. Автор топика может вообще будет делать маппинг ручками.

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

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

MS>>Лучше я скажу, в чем я не согласен в твоих высказываниях.

IT>Опять ты уходишь от вопроса.

DAL — Data Access Layer. Уровень, через который система должна получать данные из источников. Данные в этм уровни должны преобразовываться в пригодные для программы вид, с целью отделения бизнес-логики и логики персистентности данных.

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

IT>Если бы ты знал для чего нужен DAL, то и с интеграцией у тебя было бы меньше проблем

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

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

IT>У меня есть подозрение, что ты путаешь понятия мапинг и ORM.

Странно, про object-relation я и словом не обмолвился

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

IT>Что значит "маппинг должен быть настраиваемым"? Настраиваемым кем, пользователем или программистом? Поясни пожалуйста.

Я думаю, программистом (вряд ли это будет интересно конечному пользователю).

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

IT>>Ты мне так и не дал пример сложного.

MS>Мне кажется, что вообще не бывает простых систем. В каждой есть свои заморочки и сложности. А говорить, что у меня все просто и легко — пионерство

Среди законов Мерфи есть один очень мудрый закон — закон Мейера "Усложнять — просто, упрощать — сложно". Системы сложны не потому что они такие, а потому что мы их такими делаем, потому что нам так проще. Я сторонник именно такой точки зрения. И подтверждением моих слов в этом топике может служить то, что никто мне так и не дал примера когда бизнес модель должна принципиально отличатся от структуры БД. В основном только бла-бла-бла на тему как всё бывает в этой жизни не просто.

IT>>При чём тут RFD? Мы говорим о маппинге в контексте топика. Автор топика может вообще будет делать маппинг ручками.

MS>Мне показалось, что ты рассматриваешь проблему автора топика в контексте своей системы (собственно, подходы, которые ты предалгал авторы, более или менее схожи с решением RFD).

RFD — это просто удобный хелпер, рапер над ADO.NET + тупая перекладывалка из пустого в порожнее. Ни на какие принципиальные архитектурные решения RFD претендовать не собирается. Скажем так, именно это и является основным архитектурным решением в RFD — помогать, а не говорить как.

MS>DAL — Data Access Layer. Уровень, через который система должна получать данные из источников. Данные в этм уровни должны преобразовываться в пригодные для программы вид, с целью отделения бизнес-логики и логики персистентности данных.

Ключевое слово — изоляция. DAL изолирует приложение от источника данных путём перевода терминов базы данных в термины приложения и обратно.

IT>>Если бы ты знал для чего нужен DAL, то и с интеграцией у тебя было бы меньше проблем

MS>Гуд. Давай тогда распиши свое видение, как бы ты здесь с маппером решил проблему (в принципе, я уже написал, как это делать — хотелось бы послушать твой вариант).

Здесь у нас тоже самое ключевое слово — изоляция. Для этих вещей вводятся лэйеры (agents в терминах Microsoft), которые в принципе по своей природе ничем не отличаются от DAL. Та же самая изоляция приложения от источника данных, сервиса или что там у нас. При таком подходе нет необходимости тащить всё старьё из легаси кода в новое приложение, новый код можно удерживать чистым и простым.

IT>>У меня есть подозрение, что ты путаешь понятия мапинг и ORM.
MS>Странно, про object-relation я и словом не обмолвился

Тогда я тем более не понимаю о каких супер сложностях ты говоришь.

IT>>Что значит "маппинг должен быть настраиваемым"? Настраиваемым кем, пользователем или программистом? Поясни пожалуйста.

MS>Я думаю, программистом (вряд ли это будет интересно конечному пользователю).

Тогда что такое "настраиваемым"? Настраиваемым посредством чего?

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

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

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

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

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

GZ>>>Советую посмотреть (или лучше воспользоваться) готовыми ORM решениями типа Hibernate(NHibernate). Существует также огромное количество коммерческих решений (DataObjects, Versant).
_>>Что мне не нравится в подобных продуктах, что они навязывают свой стиль работы, мне больше нравятся продукты, похожие на РФД, он больше хелпер, чем чёрный ящик.
GZ>Потому что его функциональность достаточно невелика, поэтому кажется что он простой. Что касается стиля работы, то не забывай что это правильный стиль работы проверенный на реальных приложениях. Делать те же самые вещи самому, нужно угрохать достаточно много времени на постановку и продумывание + достаточные знания.

Я не очень сильно вникал, но по моему, у всех етих продуктов, БО генерятся по таблицам. Т.е они максимально похоже на саму таблицу.

_>>Если же их соеденить, то есть вероятность, что программист Вася решил, что запрос, кторый написал Вова для вебсервиса, ему тоже подходит, но вот только он добавит пару полей, при етом вебсервис который сделал Вова начнёт возвращать не множко больше данных, чем надо.
GZ>Могу предложить два способа. Первый способ, версионификация интерфейсов. Программист Вася написал клиента под интерфейс 1.1. Программисту Коле потом не хватило интерфейса 1.1 и он решил создать интерфейс 1.2 с измененными параметрами вызова. В результате, внутри сервера приложений, он изменил логику так, чтобы она работала как с интерфейсом 1.1, так и с интерфейсом 1.2.(обычно это легко проходит). И как бы, все остались при своем. В зависимости от заказанного интерфейса — бизнес-логика адаптируется под него. А чаще всего даже интерфейс 1.2 содержит(наследует) интерфейс 1.1 как свое подмножество.
GZ>Второй способ, введение как параметра функции — список полей которые хочется получить в том, или ином случае. Но я бы сказал это полумера которая была бы хороша в дополнение к первому способу. Чтобы плодить меньше версий. Ессно, если бизнес-объекты в данном виде используются только на сервере.

Иногда дополнительное поле тянет за собой и таблицу, так что одним списком полей неотделаешся.
Но смысл понял.

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

Не совсем так. То что можно видеть одному юзеру, то нельзя другому.


_>>Всё красиво, вот только я не найду достаточно веских аргументов на работе, что бы всех убедить, зачем я строю сначала БО документы, а потом ими заполняю dataset, ведь можно сразу это сделать
GZ>Можно. Любое решение должно быть достаточным. Аргументация может быть такой. Для сложных систем при реализации в схеме без явного разделения на слои, и в том числе на слой независимости от клиента, затраты на разработку новой функциональности и сопровождение растет экспотенциально. Но не забудь, что именно для сложных систем. Для простых существует принцип достаточности функционала.

Что это за принцип достаточности функционала.



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

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

MS>>Мне кажется, что вообще не бывает простых систем. В каждой есть свои заморочки и сложности. А говорить, что у меня все просто и легко — пионерство

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

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

IT>Системы сложны не потому что они такие, а потому что мы их такими делаем, потому что нам так проще. Я сторонник именно такой точки зрения.

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

IT>Здесь у нас тоже самое ключевое слово — изоляция. Для этих вещей вводятся лэйеры (agents в терминах Microsoft), которые в принципе по своей природе ничем не отличаются от DAL. Та же самая изоляция приложения от источника данных, сервиса или что там у нас. При таком подходе нет необходимости тащить всё старьё из легаси кода в новое приложение, новый код можно удерживать чистым и простым.

Ok. Только я предлагаю делать это в маппере.

IT>>>Что значит "маппинг должен быть настраиваемым"? Настраиваемым кем, пользователем или программистом? Поясни пожалуйста.

MS>>Я думаю, программистом (вряд ли это будет интересно конечному пользователю).

IT>Тогда что такое "настраиваемым"? Настраиваемым посредством чего?

В идеале — через конфигурационный файл. В нем через некую метаинфомарцию мы указываем, откуда и как брать. Затем как произвести трансформацию в наш формат, и заполнить нашу бизнес-сущность.

Не в идеале — через Data Access Components, расширающие наш маппер.

IT>И подтверждением моих слов в этом топике может служить то, что никто мне так и не дал примера когда бизнес модель должна принципиально отличатся от структуры БД. В основном только бла-бла-бла на тему как всё бывает в этой жизни не просто.

Приводу во второй и последний раз ситуацию (больше приводить нет желания и времени). Есть ситуация с интеграцией программы в уже существующую и успешно функционирующую среду. Среда работает с сущностями Товар и Заказчик. Программа — Товар (+ новое поле поставщики), Заказчик (+ новое поле поставщики), Поставщик. В целях экономии места и производительности (да и ради здравого смысла) база данных интегрируемого приложения содержит лишь информацию о поставщиках, и связи между поставщиками и другими сущностями. Все, уже не соответствие.

Переделывать базу данных под новое приложение — полный абсурд. Другие программы не работают с типом Поставщик — им этого и не нужно.

Перезаливать постоянно данные из основного хранилища в хранилище приложения тоже не имеет смысла. Проблемы с синхронизацией + дубляжом информации очень, очень не приемлимо для хорошего качества ПО.

Мне кажется, что ты не улавливаешь сути базы данных. База данных — это хранилище (+ на него постоянно нагружают логику АПП). Но никак это не хранилище для данных, приспособленных под мапперы. Здесь должны храниться данных в таком виде и формате, в котором быстрее с ними работать. Как я уже говорил, если бы это было так, то сделали эти мапперы лет эдак 40 назад, и не было бы всяких там NHibernate, ORM.NET, RFD и т.п.

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

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

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

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

IT>>Системы сложны не потому что они такие, а потому что мы их такими делаем, потому что нам так проще. Я сторонник именно такой точки зрения.

MS>Понял твою позицию. Только ты подходишь со стороны разработчика. Я же стараюсь решать проблемы со стороны бизнеса.

Ууу... как всё запущено

MS>Поэтому я считаю, что системы бывают легко реализуемые и сложно реализуемые. Измерить сложность можно по человеко-месяцам (или сразу в деньгах).

Правильно. Бывают. Ещё раз закон Мейера перечитай. Может быть ты хочешь сказать, что системы бывают большие и маленькие? Согласен. Но сложность, ещё раз повторяю, в наших головах. И некоторым головам, действительно, порой удаётся из самого простого сделать суперсложное. А уж измерение сложности в деньгах так это вообще смешно. Закажи 10 веб-страничек IBM'овскуму консалтингу и ты узнаешь что такое настоящая сложность Обещаю тебе, ты получишь настоящие солюшены с большой буквы СЫ

IT>>Здесь у нас тоже самое ключевое слово — изоляция. Для этих вещей вводятся лэйеры (agents в терминах Microsoft), которые в принципе по своей природе ничем не отличаются от DAL. Та же самая изоляция приложения от источника данных, сервиса или что там у нас. При таком подходе нет необходимости тащить всё старьё из легаси кода в новое приложение, новый код можно удерживать чистым и простым.

MS>Ok. Только я предлагаю делать это в маппере.

Да всё равно где. Маппер — это тул, хелпер, что бы ручками не перекладывать. Но тот же маппинг можно спокойно делать в рукопашную, только это больше похоже на валить лобзиком Беловежскую Пущу, но можно. Может ты всё таки имеешь ввиду ORM систему?

IT>>Тогда что такое "настраиваемым"? Настраиваемым посредством чего?

MS>В идеале — через конфигурационный файл. В нем через некую метаинфомарцию мы указываем, откуда и как брать. Затем как произвести трансформацию в наш формат, и заполнить нашу бизнес-сущность.

Конфиги — это конечно хорошо, только работы они добавляют раза в два. В RFD для них поддержка есть, сделал как-то по просьбе бывших джавистов. Но сколько я не пытался не приживаются они. Сложно всё. Реализация на атрибутах на порядок проще.

MS>Не в идеале — через Data Access Components, расширающие наш маппер.

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

IT>>И подтверждением моих слов в этом топике может служить то, что никто мне так и не дал примера когда бизнес модель должна принципиально отличатся от структуры БД. В основном только бла-бла-бла на тему как всё бывает в этой жизни не просто.

MS>Приводу во второй и последний раз ситуацию (больше приводить нет желания и времени). Есть ситуация с интеграцией программы в уже существующую и успешно функционирующую среду. Среда работает с сущностями Товар и Заказчик. Программа — Товар (+ новое поле поставщики), Заказчик (+ новое поле поставщики), Поставщик. В целях экономии места и производительности (да и ради здравого смысла) база данных интегрируемого приложения содержит лишь информацию о поставщиках, и связи между поставщиками и другими сущностями. Все, уже не соответствие.

MS>Переделывать базу данных под новое приложение — полный абсурд. Другие программы не работают с типом Поставщик — им этого и не нужно.

MS>Перезаливать постоянно данные из основного хранилища в хранилище приложения тоже не имеет смысла. Проблемы с синхронизацией + дубляжом информации очень, очень не приемлимо для хорошего качества ПО.

MS>Мне кажется, что ты не улавливаешь сути базы данных.

Да это понятно, куда нам деревенским. Тем более что я и сейчас уловить не могу... проблема где? В чём проблема? В том что у тебя три таблицы лежат в двух разных базах данных? Ну и что здесь делает сложным маппинг? Или твой маппер не умеет одновременно коннектится сразу к двум БД? Тогда да... В чём проблема, я правда не понял.

MS>База данных — это хранилище (+ на него постоянно нагружают логику АПП).

Вот за это надо сразу к стенке.

MS>Но никак это не хранилище для данных, приспособленных под мапперы. Здесь должны храниться данных в таком виде и формате, в котором быстрее с ними работать.

Блин. Я наверное и правда тупею на чужбине... И как это отражается на сложности маппинга? Вот хранение данных в двух базах — это да, замедлит работу и усложнит реализацию доступа к данным, но при чём тут быстродействие и маппинг? Быстродействие — это ключи и индексы, маппинг — это построение соответствий между полями таблиц и полями и свойствами классов. В чём противоречие?

MS>Как я уже говорил, если бы это было так, то сделали эти мапперы лет эдак 40 назад, и не было бы всяких там NHibernate, ORM.NET, RFD и т.п.

Для маппинга нужно откуда-то брать метадату. 40 лет назад не было ещё ни рефлекшина, ни даже XML'я. Да и сам по себе маппинг был не актуален. Он делался с помощью простого кастинга void* к типизированному указателю. Я такое ещё лет 10-12 назад умел. А теперь ты фиг чего откастишь, надо перекладывать из резалтсета в поля класса. Вот чтобы эту вновь образовавшуюся дырку заткнуть и придумали маппинг.

Здравствуйте, 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 ?