.Net Заполнить поля класса из таблицы

[Jeeser]

Наша контора недавно перешла на .Net (на Делфи 8 конкренто) и пишется довольно большой проект фактически с нуля.

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

classnamefield := tablenamefield и наоборот.

А вместо этого, что нибудь в духе MyObjLoad(classname, tablename) и такое же для Update, Insert.

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

[JustMax]

Наша контора недавно перешла на .Net (на Делфи 8 конкренто) и пишется довольно большой проект фактически с нуля.

[offtopic]
Ну вешайтесь...
[/offtopic]

Вообще с ORM довольно тяжело в .NET (ADO.NET), ну то есть вообще никак. О продуктах уровня TopLink - я уж вообще молчу.
Ну вот вроде скоро в .NET ObjectSpace появится - может полегче станет, а то ADO.NET такая убогость (провокация)

[Strannik223]

Да, готовых ORM не поставляется, это вам не Джава. Мы сами писали, получилось довольно неплохо. В двух словах: размечаете классы и поля CustomAttributes, при старте приложения парсите все assembly, и потом по этой информации динамически генерите SQL для insert, update,delete, select каждого класса который отмечен атрибутом. Ну естественно все это оптимизируется, кешируется.
Эта работа интересная и увлекательная, успехов!

<offtopic>
Вешаться не надо.
</>

[Strannik223]

Да, еще, ради Бога, не поддавайтесь на соблазн использовать DataSet. Все что я видел на его основе было просто СТРАШНЫМ.

[Niky]

И что же там, интересно, было такого СТРАШНОГО?

[Strannik223]

И что же там, интересно, было такого СТРАШНОГО?

У меня есть интересный опыт. Пришел на фирму, а там как раз на основе DataSet сделана подсистема хранения обьектов. Я глянул в профайлере что операция создать, удалить, проапдейтить объект вызывает 237 обращений к сиквел серверу. После того как я пришел в себя, по вечерам за неделю склепал прототип того что я описал выше. Так как такое решение уже применялось на предыдущей работе то был "эффект второй системы".
В результате скорость в 30 раз увеличилась :)
Были еще проэкты, и я что то закономернось замечать стал, как DataSet используется, так это делается абсолютно безмозгло.

Можно конечно заявить что дело не в DataSet, а в программере и я даже частично соглашусь, но я не вижу смысла использовать эту надстройку над DataReader в таком деле как построение ORM

[Niky]

Ну, смысл-то найти можно. Например, задачу Jesser'а как раз легко решить с помощью typed datasets. Заодно решается проблема построения коллекций и relations объектов. А довести до абсурда можно любую идею, из чего не следует, что она никуда не годится.

[lozzy]

Ну, смысл-то найти можно. Например, задачу Jesser'а как раз легко решить с помощью typed datasets. Заодно решается проблема построения коллекций и relations объектов. А довести до абсурда можно любую идею, из чего не следует, что она никуда не годится.

TypedDataSet-s имеют свои грабли. Например, при каждом изменении структуры БД приходится удалять схему и создавать ее заново, потом перекомпилять и т.д. Вообщем неудобно, но если структура устоялась, то юзать в принципе можно.

Кроме этого есть проблемы с передачей TDS через веб-сервисы. Ну и размер аппликации пухнет с необыкновенной скоростью, а перфоманс деградирует, как тут уже замечали.

[cityzen]

Наша контора недавно перешла на .Net (на Делфи 8 конкренто) и пишется довольно большой проект фактически с нуля.

В проекте огромное количество классов, которые напрямую отражают таблицы в базе данных, и эти таблицы, также как и классы, постоянно модифицируются.

Offtopic, из чистого любопытства - а какие преимушества дает такой дизайн, когда каждая таблица оборачивается в зеркальный класс?

[Niky]

...
TypedDataSet-s имеют свои грабли. Например, при каждом изменении структуры БД приходится удалять схему и создавать ее заново, потом перекомпилять и т.д. Вообщем неудобно, но если структура устоялась, то юзать в принципе можно.

Грабли есть везде. В подходе Странника, как я понял (извините еслт не прав), в таком случае придется заново расставлять custom attributes.

Кроме этого есть проблемы с передачей TDS через веб-сервисы. Ну и размер аппликации пухнет с необыкновенной скоростью, а перфоманс деградирует, как тут уже замечали.

С передачей data objects собственного производства проблемы тоже могут возникнуть.

Да, готовых ORM не поставляется, это вам не Джава.

ORM.NET, Deklarit, LLBLGen... You name it.

[Strannik223]

...
TypedDataSet-s имеют свои грабли. Например, при каждом изменении структуры БД приходится удалять схему и создавать ее заново, потом перекомпилять и т.д. Вообщем неудобно, но если структура устоялась, то юзать в принципе можно.

Грабли есть везде. В подходе Странника, как я понял (извините еслт не прав), в таком случае придется заново расставлять custom attributes.

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

[Strannik223]

Offtopic, из чистого любопытства - а какие преимушества дает такой дизайн, когда каждая таблица оборачивается в зеркальный класс?

Например простота :)
Но в реальности обязательно встретится класс который в базе хранится как 2 (или более) таблицы, связаные отношенеим. Нарпимер в таблице Location может быть поле country, которое ссылается на справочную таблицу Country
Так же желательно иметь возможность загружать композитные объекты, например объект Contact содержит поле PhoneNo, которое в свою очередь является самостоятельным объектом, или даже списком объестов (one-to-many).

[Jeeser]

спасибо за ответы, почерпнул много полезного.

По поводу дизайна получилось следующее: фирма наняла специального архитекта, который 2 месяца прилетал к нам из Торонто, говорил важные разговоры и потом сделал призентацию и объяснил, как все будет работать. Основная идея призентации была: "новые компьютерные технологии и защита компьютерых программ" (c). или 'xml is everywhere' и 'защита от злобных хакеров'. Мужик нарисовал квадратик с сервером (HHTPSoap) который для внешнего мира предоставляет 2 метода - один для обычного взаимодействия, второй для администрирования. В качестве параметров передается сериализованный (serialized) объект, в виде xml string. Сервер читает эту строку и десириализует ее в соответвующий объект и в зависимости от того, какие свойства этого объекта, производит его обработку и выдает обратно клиетну результат в виде опять же сериализованного объекта. Сам архитект утверждает, что при таком подходе во первых все по модному будет, очень xml'но, а во вторих очень безопасно - большинство обычных серверов открывают миру кучу методов (login, connect ... ) а наш только 2. Получается следующее - плохие парни экспознули оба наших метода - ну и не беда, они передают в качестве параметра одного из методов 'hello world', а сервер их посылает - потому как не может десериализовать этот объект ни в один из существующих в системе. Плохиши уходят размазывая слёзы и проклиная умных разработчиков, а мы, с достойной и спокойной улыбкой, говорим нашим клиентам: 'не волнуйтесь, вы под надежной защитой'. все радуются, пожимают друг-другу руки, поют песню и т.д.
Архитект говорит что сериализовнный xml мы еще и страшно заинкриптим, и тогда уж у врага не будет ни одного шанса.

[Strannik223]

1. По поводу секурити. Лож п****ь и пропаганда (с) приписывают Троцкому
Возьмем любое Веб приложение, оно то же исключительно по http доступно, но утверждать что это причина его неуязвимости не станет никто. Я лично на одном из проектов взломал продакшен сервер при помощи sql-injecting техники. От чего действительно защищает .net, так же как и Джава так это от buffer-overflow. Но это хоть и одина из самых распостраненных техник но далеко не единственная.

"новые компьютерные технологии и защита компьютерых программ" (c). или 'xml is everywhere'

xml - чрезвычайно удобно, но опять же кроме ускорения и упрощения девелопмента никаких прямых эффектов не имеет. Хотя эти самые эффекты настолько ощутимы что они из количества переростают в качество.

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

Думаю что это было все таки не 2 метода а 2 интерфейса
Дальнейшее объяснение сериализации безусловно полезно но в .net усе автоматом будет (по крайней мере пока не возникнет необходимость хитрый объект ручками сериализовать)
Советую срочно разбиратся с примерами програм которые идут с .net framework под разделом Remoting.

Сервер читает эту строку и десириализует ее в соответвующий объект и в зависимости от того, какие свойства этого объекта, производит его обработку и выдает обратно клиетну результат в виде опять же сериализованного объекта. Сам архитект утверждает, что при таком подходе во первых все по модному будет, очень xml'но, а во вторих очень безопасно - большинство обычных серверов открывают миру кучу методов (login, connect ... ) а наш только 2.

Я конечно понимаю что консультант должен привирать что бы все видели какие прекрасные идеи он несет, но всему же есть предел
Во первых, методов все таки буде туча. Подумай сам, что может сделать клиент если он способен вызвать аж 2 метода на сервере, один из которых логин Это наверное сверхтонкий клиент, я бы сказал микроскопический, котроый в состоянии исполнять аж одну функцию!

Получается следующее - плохие парни экспознули оба наших метода - ну и не беда, они передают в качестве параметра одного из методов 'hello world', а сервер их посылает - потому как не может десериализовать этот объект ни в один из существующих в системе. Плохиши уходят размазывая слёзы и проклиная умных разработчиков

А Кибальчиши почесав репу клепают прямо в текстовом редакторе xml в котором описывают объект со всеми его пропертями и премиленько вызывают метод.
Хотел бы я спросить этого консалтера почему это вдруг вызвать удаленный метод бинарно вруг стало просто, а xml - сложно. Настоящего хакера бинарный формат не остановит, но для любопытствующих именно SOAP то что надо.
Консультант конечно не упомянул что WSDL дает полное описание всех методов и параметров, описывает все поля которые должны быть у объектов параметров, вобщем вся информация небоходимая для вызова метода

Архитект говорит что сериализовнный xml мы еще и страшно заинкриптим

Первая здравая мысль. Это единственное что защищает от просмотра трафика. https использовать и никаких гвоздей.

Итого, архитетурой предусмотрена защита от прослушивания. Все остальное - лапша.

[Jeeser]

Сервер читает эту строку и десириализует ее в соответвующий объект и в зависимости от того, какие свойства этого объекта, производит его обработку и выдает обратно клиетну результат в виде опять же сериализованного объекта. Сам архитект утверждает, что при таком подходе во первых все по модному будет, очень xml'но, а во вторих очень безопасно - большинство обычных серверов открывают миру кучу методов (login, connect ... ) а наш только 2.

Я конечно понимаю что консультант должен привирать что бы все видели какие прекрасные идеи он несет, но всему же есть предел
Во первых, методов все таки буде туча. Подумай сам, что может сделать клиент если он способен вызвать аж 2 метода на сервере, один из которых логин Это наверное сверхтонкий клиент, я бы сказал микроскопический, котроый в состоянии исполнять аж одну функцию!

Именно два. Реально при таком подходе можно и одним обойтись. Напрмер: на клиенте создаю объект User, у него есть свойтсво UserAction перечисляемого типа + у User еще есть LoginName и Password. Устанавливаем UserAction в что-нибудь типа uaLogin и засылаем на сервер в виде строки + засылаем тип объекта (что теоретически можно не делать).
Сервер получает эту строку, создает из нее обект, читает какую Action запустить и соответственно запускает. И посылает обратно тот же обект но с установленным свойством Logged.

Получается следующее - плохие парни экспознули оба наших метода - ну и не беда, они передают в качестве параметра одного из методов 'hello world', а сервер их посылает - потому как не может десериализовать этот объект ни в один из существующих в системе. Плохиши уходят размазывая слёзы и проклиная умных разработчиков

А Кибальчиши почесав репу клепают прямо в текстовом редакторе xml в котором описывают объект со всеми его пропертями и премиленько вызывают метод.
Хотел бы я спросить этого консалтера почему это вдруг вызвать удаленный метод бинарно вруг стало просто, а xml - сложно. Настоящего хакера бинарный формат не остановит, но для любопытствующих именно SOAP то что надо.
Консультант конечно не упомянул что WSDL дает полное описание всех методов и параметров, описывает все поля которые должны быть у объектов параметров, вобщем вся информация небоходимая для вызова метода

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