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

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

IT>>Если и сложнее, то не намного.
M>А если учесть, что частенько объект достаточно просто сериализовать, то xml получается проще...

Просто вряд ли получится. Придется dml псевдо-команды в xml'ном виде вводить.

M>Но на сервере с ним надо будет повозиться.

Ага.
А по сути перенести весь алгоритм формирования батча, о котором упоминал Sinclair, из C# (Delphi и т.п.) в TSQL.

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

kig>Просто вряд ли получится. Придется dml псевдо-команды в xml'ном виде вводить.
Зачем???!

kig>А по сути перенести весь алгоритм формирования батча, о котором упоминал Sinclair, из C# (Delphi и т.п.) в TSQL.
Да, только выполнять его придется наиболее естественным для T-SQL образом, тоесть реляционными запросами, что приятно.

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

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

kig>>Просто вряд ли получится. Придется dml псевдо-команды в xml'ном виде вводить.
M>Зачем???!
Ну засериализовал ты объект. И как понять, чего ты с ним будешь делать на серверной стороне? Добавлять, удалять, апдейтить и т.д.?


kig>>А по сути перенести весь алгоритм формирования батча, о котором упоминал Sinclair, из C# (Delphi и т.п.) в TSQL.
M>Да, только выполнять его придется наиболее естественным для T-SQL образом, тоесть реляционными запросами, что приятно.
Сразу вопросик — а разве батч, приехавший на сервер, состоит не из реляционных запросов?
Поясни "выполнять его придется наиболее естественным для T-SQL образом". Парсинг/преобразование через MSXML в реляционный код — это естественный путь для T-SQL?

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

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

kig>Сразу вопросик — а разве батч, приехавший на сервер, состоит не из реляционных запросов?
В этом случае проблемы с формированием его на клиенте, от которых мы пытаемся уйти формируя xml легким движением руки.

kig>Поясни "выполнять его придется наиболее естественным для T-SQL образом". Парсинг/преобразование через MSXML в реляционный код — это естественный путь для T-SQL?
Это делается прозрачно для разработчика, одним запросом, и на выходе получается реляционная таблица данные из которой рспихиваются куда надо.

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

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

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

Итого: каждый класс объектов * действия с такими объектами = кол-во серверных СП для этого класса. Где, в отличии от классики, имеем один параметр text/ntext, принимающий сериализованный в xml объект этого класса. А внутри таких СП преобразуем xml в реляционный код. И в чем выгрыш такого подхода? По сравнению с классическим подходом. Тем, что входной параметр один? И все?

Вот мои минусы такого подхода:
1. Кол-во СП == классическому — выгрыша никакого.
2. Возвращаемые параметры? По логике, надо тоже в xml возвращать, а то "протокол" какой-то несимметричный получается.
3. Полная потеря "типизации" => контроль входного xml на предмет ошибок => аналогия: представь себе C# код, где у методов один параметр string. С xml внутри.


kig>>Сразу вопросик — а разве батч, приехавший на сервер, состоит не из реляционных запросов?
M>В этом случае проблемы с формированием его на клиенте, от которых мы пытаемся уйти формируя xml легким движением руки.

И тем же легким движением руки создавая головную боль разработчикам таких СП, в плане манипулирования с xml. Особенно при массовом рефакторинге. А соотвественно и тестерам. Которые будут ловить несоответствия в рантайме.
Хотя надыбать/написать тулзу, которая по классическим СП генерит методы в код C#, проблем нет.

kig>>Поясни "выполнять его придется наиболее естественным для T-SQL образом". Парсинг/преобразование через MSXML в реляционный код — это естественный путь для T-SQL?
M>Это делается прозрачно для разработчика, одним запросом, и на выходе получается реляционная таблица данные из которой рспихиваются куда надо.
Я смотрю, ты T-SQL писателей за разработчиков не держишь.

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

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

G2>>Таблица Examinations не может содержать поля типа NULL, а также одна запись в таблице Patients c PatientID должен будет говорить о наличие только одной записи в Examinations c ExamID.

IT>Т.е. у тебя связь один-к-одному/

Если точнее, должен также участвововать параметр @StartTimeStamp, т.е. я хочу, чтобы на конкретную StartTimeStamp была одна запись в таблице Patients c PatientID и одной записью в Examinations c ExamID. Для другого @StartTimeStamp, изменился только ExamID.

IT>С той лишь разницей, что вызывать спроки и контролировать транзакцию будет BL. Но если у тебя связь 1-1, то можно вообще всё сделать в одной процедуре.
Т.е 2 insert'a в 2 таблицах в одной процедуре?

IT>>>Тогда, например в ADO.NET, это свелось бы к вызову ExecuteScalar, что намного проще обработки output параметра.
G2>>Т.е самому считать инкремент или если уже существует запись, то считывать и передавать в ExecuteScalar?

IT>Что значит "уже существует"? Вообще я здесь меню ввиду output параметр vs. select.
Пример, если можно, пожалуйста, для меня тяжело понимать на словах.

IT>>>Почему не хранить просто коллекцию объектов?
В ArrayList?
IT>>>Получается несколько нелогично.
Почему?

G2>>Подсмотрел в "Designing Data Tier Components and Passind Data Through Tier".
G2>>Глава "How to Represent Collections and Hierarchies of Data in a Business Entity".

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

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

kig>Итого: каждый класс объектов * действия с такими объектами = кол-во серверных СП для этого класса.
В общем случае нет.

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

kig>1. Кол-во СП == классическому — выгрыша никакого.
Это не минус, это просто отсутствие плюсов да и то в самом худшем случае.

kig>2. Возвращаемые параметры? По логике, надо тоже в xml возвращать, а то "протокол" какой-то несимметричный получается.
По логике, параметры должны возвращаться в реляционном рекордсете и никакой несимметричности тут нет.

kig>3. Полная потеря "типизации" => контроль входного xml на предмет ошибок =>
Никакой потери, все проверки можно сделать после преобразования xml-я в реляционную таблицу.

kig> аналогия: представь себе C# код, где у методов один параметр string. С xml внутри.
Ну ты же не в ручную это будешь разбирать, сделаешь deserialize и все косяки тут же вылезут, так и здесь. Так что не работает аналогия..


kig>И тем же легким движением руки создавая головную боль разработчикам таких СП, в плане манипулирования с xml.
Да нет этой головной боли, один раз OPENXML вызвать — проблема что ли? Вся фишка в том, что даже сейчас преобразование xml-я в реляционную таблицу на сервере делается стажером за 10 минут, я проверял.

kig> Особенно при массовом рефакторинге. А соотвественно и тестерам. Которые будут ловить несоответствия в рантайме.
А в классическом варианте при рефакторинге все гладко проходит? Нет конечно, та же фигня, только в профиль. Это проблема передачи данных между разными средами с разными формтами и решается она только ручным контролем на принимающей и передающей стороне. И xml, в данном случае, помогает хотя бы отчасти это дело автоматизировать, пускай и чуть большей затратой ресурсов на парсинг параметров. Но в большинстве случаев, если не брать в рассчет самые примитивные, это вполне приемлимая цена.

kig>Я смотрю, ты T-SQL писателей за разработчиков не держишь.
Еще как держу, пусть делом занимаются, а не параметры в табличку перекладывают...

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

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

kig>>Итого: каждый класс объектов * действия с такими объектами = кол-во серверных СП для этого класса.
M>В общем случае нет.

Т.е. СП для работы с композитными объектами (в реляции — мастер-детейл). Правильно понял?

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

kig>>1. Кол-во СП == классическому — выгрыша никакого.
M>Это не минус, это просто отсутствие плюсов да и то в самом худшем случае.

kig>>2. Возвращаемые параметры? По логике, надо тоже в xml возвращать, а то "протокол" какой-то несимметричный получается.
M>По логике, параметры должны возвращаться в реляционном рекордсете и никакой несимметричности тут нет.

kig>>3. Полная потеря "типизации" => контроль входного xml на предмет ошибок =>
M>Никакой потери, все проверки можно сделать после преобразования xml-я в реляционную таблицу.

Т.е. все-таки делать? Блин... опять рантайм.

kig>> аналогия: представь себе C# код, где у методов один параметр string. С xml внутри.
M>Ну ты же не в ручную это будешь разбирать, сделаешь deserialize и все косяки тут же вылезут, так и здесь. Так что не работает аналогия..

Работает. Int'у ты string не присвоишь. Тебя компилятор пошлет (о слаботипизированных языках не говорим). "сделаешь deserialize и все косяки тут же вылезут" — это в рантайме. А это лишние затраты на тестирование. Хотя бы быть уверенным, что ты все ветки покрыл. А так это компилятор на себя берет. Почувствуй разницу.


kig>>И тем же легким движением руки создавая головную боль разработчикам таких СП, в плане манипулирования с xml.
M>Да нет этой головной боли, один раз OPENXML вызвать — проблема что ли? Вся фишка в том, что даже сейчас преобразование xml-я в реляционную таблицу на сервере делается стажером за 10 минут, я проверял.


kig>> Особенно при массовом рефакторинге. А соотвественно и тестерам. Которые будут ловить несоответствия в рантайме.
M>А в классическом варианте при рефакторинге все гладко проходит? Нет конечно, та же фигня, только в профиль. Это проблема передачи данных между разными средами с разными формтами и решается она только ручным контролем на принимающей и передающей стороне. И xml, в данном случае, помогает хотя бы отчасти это дело автоматизировать, пускай и чуть большей затратой ресурсов на парсинг параметров. Но в большинстве случаев, если не брать в рассчет самые примитивные, это вполне приемлимая цена.

Между средами можно по разному передавать. Можно, как предлагаешь ты. Вводя промежуточный слой в виде xml. Но в этом случае ты
откладываешь разбор полетов (ошибки) до момента запуска прилолжения. И появляется у тебя ручной контроль на сторонах. Например, на сложных объектах, если у тебя изменилось 1-ко-многим на многие-ко-многим тебе придется rowpattern в OPENXML рефакторить.

А можно сгенерить из схемы по СП'ам C# код. И этот код уже жестко типизирован. Т.е. в этом случае в качестве "промежуточного" слоя используется результат работы генератора, который представления одного слоя переводит в представления другого. В нашем случае — сигнатуры СП в C# код. А таких генераторов в инете полным-полно (да и самому слабать труда не составит).

Правда в твоем варианте как бы "автоматизируется" передача сложных объектов одним махом на сервер и освобождает разработчика сложный объект персистить на сервер. В варианте через генерацию в C# код для этого придется повозиться. Или руками. Или создавая тулзу, которая имея описание сложных объектов (хотя бы в виде абстрактных классов или интерфейсов) умеет генерить код построения батча.

kig>>Я смотрю, ты T-SQL писателей за разработчиков не держишь.
M>Еще как держу, пусть делом занимаются, а не параметры в табличку перекладывают...

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

kig>Т.е. СП для работы с композитными объектами (в реляции — мастер-детейл). Правильно понял?
Именно, для простых объектов не имеет смысла канитель с xml-ем затевать...

kig>Т.е. все-таки делать? Блин... опять рантайм.
Ну ясен байт..

kig>"сделаешь deserialize и все косяки тут же вылезут" — это в рантайме
А по другому никак.

kig>Между средами можно по разному передавать. Можно, как предлагаешь ты. Вводя промежуточный слой в виде xml. Но в этом случае ты
kig>откладываешь разбор полетов (ошибки) до момента запуска прилолжения.
Хранимку по другому в принципе не проверишь.

kig> Например, на сложных объектах, если у тебя изменилось 1-ко-многим на многие-ко-многим тебе придется rowpattern в OPENXML рефакторить.
А в классическом варианте ничего рефакторить не придется?

kig>А можно сгенерить из схемы по СП'ам C# код. И этот код уже жестко типизирован.
Каким образом? Он типизирован только по простым типам, string и int, и все, а это не интересно и утомительно.

kig>Правда в твоем варианте как бы "автоматизируется" передача сложных объектов одним махом на сервер и освобождает разработчика сложный объект персистить на сервер.
Вот ради этого все и затевается. Головной боли снимает уйму, проверено...

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

kig>А можно сгенерить из схемы по СП'ам C# код. И этот код уже жестко типизирован. Т.е. в этом случае в качестве "промежуточного" слоя используется результат работы генератора, который представления одного слоя переводит в представления другого. В нашем случае — сигнатуры СП в C# код. А таких генераторов в инете полным-полно (да и самому слабать труда не составит).
Гм. А кто мешает вместо типизированных оберток над sp генерировать тем самым генератором сразу классы, оформленные атрибутами xml-маппинга? Тогда сериализация делается одним движением руки, заполнение данных полностью статически валидируется, и избавляемся от проблем с множественными раунд-трипами. А?

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

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

kig>>А можно сгенерить из схемы по СП'ам C# код. И этот код уже жестко типизирован. Т.е. в этом случае в качестве "промежуточного" слоя используется результат работы генератора, который представления одного слоя переводит в представления другого. В нашем случае — сигнатуры СП в C# код. А таких генераторов в инете полным-полно (да и самому слабать труда не составит).
S>Гм. А кто мешает вместо типизированных оберток над sp генерировать тем самым генератором сразу классы, оформленные атрибутами xml-маппинга? Тогда сериализация делается одним движением руки, заполнение данных полностью статически валидируется, и избавляемся от проблем с множественными раунд-трипами. А?

Да ни кто не мешает. Только в ветке постоянно о СП говорят. Ты сам приводил пример батча, в котором СП.

Если начинать с нуля генераторы писать, по схеме БД просто так маппинг не сгенерить. По сложной БД. По СП — в лет.

"оформленные атрибутами xml-маппинга" — А какой в них смысл? Если уж генерить нормальные орм-классы с полной поддержкой crud, то и атрибуты не нужны. В такие классы необходимо сразу генерить код, который используется для создания батчей.

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

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

kig>>Т.е. СП для работы с композитными объектами (в реляции — мастер-детейл). Правильно понял?
M>Именно, для простых объектов не имеет смысла канитель с xml-ем затевать...

Ну а для составных ИМХО лучше батч. Состоящий из СП, если по религиозным соображениям без не могут, или из обычных dml.
(Я ниже Sinclair отписал по поводу СП. Мы, например, работаем вообще без них.)

kig>>Т.е. все-таки делать? Блин... опять рантайм.
M>Ну ясен байт..

Не гуд...

kig>>"сделаешь deserialize и все косяки тут же вылезут" — это в рантайме
M>А по другому никак.

Тоже не гуд. Уж лучше жесткими типами.

kig>>Между средами можно по разному передавать. Можно, как предлагаешь ты. Вводя промежуточный слой в виде xml. Но в этом случае ты
kig>>откладываешь разбор полетов (ошибки) до момента запуска прилолжения.
M>Хранимку по другому в принципе не проверишь.

А на кой она тогда нужна?

kig>> Например, на сложных объектах, если у тебя изменилось 1-ко-многим на многие-ко-многим тебе придется rowpattern в OPENXML рефакторить.
M>А в классическом варианте ничего рефакторить не придется?

Если нормальный орм — только в тех местах, которые пользуются результатом генерации. Изменилась схема БД, поправили проект орм, получили новые crud-классы. Дальше ловим в компиляции ошибки.

kig>>А можно сгенерить из схемы по СП'ам C# код. И этот код уже жестко типизирован.
M>Каким образом? Он типизирован только по простым типам, string и int, и все, а это не интересно и утомительно.

kig>>Правда в твоем варианте как бы "автоматизируется" передача сложных объектов одним махом на сервер и освобождает разработчика сложный объект персистить на сервер.
M>Вот ради этого все и затевается. Головной боли снимает уйму, проверено...

Только "автоматизируется" по сути выражается через написание ручками соответствующих xpath-выражений в rowpattern.

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

kig>Ну а для составных ИМХО лучше батч.
Автогенеренный? Далеко не всегда подходит, а в рукопашную его пилить — занятие утомительное и от ручного контроля типов не избавляет...

kig>А на кой она тогда нужна?
А на той, что логика хранения данных может довольно серьезно отличаться от вида самих объектов причем так, что никакой генератор не разгребет.
А в таких случаях, либо в рукопашную, либо через xml... Через xml проще.

kig>Только "автоматизируется" по сути выражается через написание ручками соответствующих xpath-выражений в rowpattern.
Да, но это кораздо проще чем каждый параметр в ручную по табличкам раскладывать.

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

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

kig>>Ну а для составных ИМХО лучше батч.
M>Автогенеренный? Далеко не всегда подходит, а в рукопашную его пилить — занятие утомительное и от ручного контроля типов не избавляет...

kig>>А на кой она тогда нужна?
M>А на той, что логика хранения данных может довольно серьезно отличаться от вида самих объектов причем так, что никакой генератор не разгребет.
M>А в таких случаях, либо в рукопашную, либо через xml... Через xml проще.

Пример привел бы. И процент таких ... исключений.
kig>>Только "автоматизируется" по сути выражается через написание ручками соответствующих xpath-выражений в rowpattern.
M>Да, но это кораздо проще чем каждый параметр в ручную по табличкам раскладывать.

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

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

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

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

kig>>Пример привел бы. И процент таких ... исключений.
M>Пример чего?

Вот этого:


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

M>Ну вот, например, тебе надо порядок изменений таблиц проконтролировать, чтобы на дедлоки или какую несогласованность не нарваться

Дык это вопрос инструментария.

M>или, упаси байт, хинтом каким воспользоваться и что будет делать генератор?

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

Я, конечно, приводил пример батча. Но ты почему-то напираешь на то, что генератор батча можно генерировать. Справедливость требует отметить, что классы с разметкой для XML -сериализации генерить еще проще.

kig>Если начинать с нуля генераторы писать, по схеме БД просто так маппинг не сгенерить. По сложной БД. По СП — в лет.
Не, надо наоборот. По схеме генерить классы, мапперы, таблички и SP.
kig>"оформленные атрибутами xml-маппинга" — А какой в них смысл?
Очень простой. Велосипед потому что.
kig>Если уж генерить нормальные орм-классы с полной поддержкой crud, то и атрибуты не нужны. В такие классы необходимо сразу генерить код, который используется для создания батчей.
О-о, как круто. При наличии атрибутов код маппинга пишется влет: просто сериализуем класс стандартной сериализацией и отдаем соответствующей хранимке. Имя хранимки — это +1 атрибут. Всё. Упражнение на час. А генератор рукопашной поддержки ОРМ — намного дольше.

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

Ну давай по пунктам:

S>Я, конечно, приводил пример батча. Но ты почему-то напираешь на то, что генератор батча можно генерировать. Справедливость требует отметить, что классы с разметкой для XML -сериализации генерить еще проще.

Что в лоб, что по лбу.
Но то, что создает батч в рантайме, сосредоточено в одном месте.
А в твоем варианте для полноты картины надо не забыть сгенерить СП, которые сериализованные объекты понимают. В результате ты получаешь логику CRUD, размазанную по разным местам. По коду, ну, например C#. И по коду T-SQL. Это не гуд.


kig>>Если начинать с нуля генераторы писать, по схеме БД просто так маппинг не сгенерить. По сложной БД. По СП — в лет.
S>Не, надо наоборот.

Я тебе так и написал — по схеме БД не сгенерить. Информации не хватит.

S>По схеме генерить классы, мапперы, таблички и SP.

Ключевой момент. Вот теперь бы поподробнее, чем и как создается такая схема?

kig>>"оформленные атрибутами xml-маппинга" — А какой в них смысл?
S>Очень простой. Велосипед потому что.

Ну кому что нравится.

kig>>Если уж генерить нормальные орм-классы с полной поддержкой crud, то и атрибуты не нужны. В такие классы необходимо сразу генерить код, который используется для создания батчей.
S>О-о, как круто. При наличии атрибутов код маппинга пишется влет: просто сериализуем класс стандартной сериализацией и отдаем соответствующей хранимке. Имя хранимки — это +1 атрибут. Всё. Упражнение на час. А генератор рукопашной поддержки ОРМ — намного дольше.

Пояснил бы, что такое "рукопашной поддержки".
Кстати, а генерацция "соответсвующих хранимок" это не кусочек ОРМ? И как там с рукопашной поддержкой?

M>

M>public Class User
M>{
M>   public string Name{get{...}set{...}}
M>   //....
M>}

M>

M>для него пишется класс БД:
M>

M>public class CUserDB
M>{
M>    public static void Create(CUser p_user);
M>    public static void CreateRelation(CUser p_user,CRole p_role);
M>    public static void DeleteRelation(CUser p_user,CRole p_role);
M>    public static void Delete(CUser p_user);
M>    public static void Update(CUser p_user);
M>    public static CUser Load(string p_sUserName);
M>    public static CUser Load(int p_iUserID);
M>    public static CUserCollection GetList();
M>    public static CUserCollection GetList(CRole p_role);
M>    public static SQLDataReader GetListReader();
M>    protected static CUser GetObjectFromReader(SqlDataReader p_reader);
M>}
M>

пришли плз пример реализации этого дела
psy-factory@mail.ru
спс))

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

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

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

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

PZT>>можно использовать готовый OR-mapping tool.

А>А какие готовые OR-mapping tools в природе существуют ?
А>Дайте ,плиз, линки кто чем пользовался.

Сюда смотрели ?