.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 что на сервер передаются в качестве параметров две строковх переменных никак помочь им не может - там же нет никакого описания структуры объекта - просто строки.

[Strannik223]

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

Ууу как все запущено. А говорил новые технологии. С таким же успехом можно это сделать на TCP socket И где здесь выигрыш от применения xml? Какая разница, вызывать ли

Code: Select all

CallSOAPRemote(Action action, byte[] serializedParameters);
Или 
CallWinSockRemote(Action action, byte[] serializedParameters);

По моему никакой. Это что то вроде каменного топора с ручкой из углеволокна.

Возвращаясь к плохишам. Допустим в старорежимной системе выставлено наружу 500 функций. Что это дает хакеру? Ничего, он даже имен функций не знает, и форматов данных. То есть защита основана на незнании форматов данных. Это защитой считаться не может.
Теперь про ваши 2 функции: что поменялось по сравнению например с DCOM or RPC. Транспортный протокол. Вы будете использовать SOAP исключительно как транспорт а не как механизм вызова удаленных функций, для чего он собсвенно и был придуман.

Remoting был придуман для того что бы сделать прозрачным местонахождение вызываемого объекта. Я недавно делал приложение у которого есть 2 варианта поставки: remote server & local server. Для удаленного сервера функции вызываются удаленно а для локального локально. При этом код клиента одинаковый для обоих этих вариантов. Клиентский код не осведомлен, с каким экземпляром сервера он работает, удаленным или локальным. Если надо залогиниться то

Code: Select all

IUser user =  Server.Instance.GetUser();
user.Login("vasia", 'password');
user.Name = "Petia";
user.Save();

В зависимости от того каким экземпляром сервера был проинициализирован синглтон Server, вызов пойдет либо на удаленную машину либо в локальную assembly. И если это удаленный сервер то будет возвращена Proxy, которая выглядит так же как и настоящий объект, только все вызовы перенаправляет на сервер и возвращает результат. Самое замечательное что не надо писать никакого кода для заглушки. .Net все сделает сам используя reflection.

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

Недостатки вашей модели:
1. Надо иметь в каждом объекте исскуственное поле action.
2. Action будет постоянно и всюду модифицироватся по мере добавления и удаления функций.
3. На сервере будет громадный демультиплексор

Code: Select all

switch (typeOfObject) {
  case "User"
    switch(Action) {
      case "login":
      case "save"
      case "load"
      ..
    }
...
}

При каждом изменении функции его надо будет править вручную,
Назвать это современным подходом! Это было модно лет 10 назад.

4. Никакой проверки типов. Никакой проверки количества и типов параметров.
Только не говорите что можно сделать

Code: Select all

  case "User" :
...
      case "login"
        if (params.length != 4 || params[0].GetType() == typeof(string)
          || params[1].GetType == typeof(int)
          ..... ну вобщем вы поняли)

5, прийдется писать 2 разных класса для клиента и для сервера для каждого бизнес обьекта!!!. Сервеный будет делать собсвенно бизнес логику, а клиентский

Code: Select all

class User {
  public Save() {
    CallRemote(Action.Save, this.GetType().Name, SerializeMe(this));
  }
...
}

То есть ручное написание proxy. При большем количестве объектов и частых изменениях мало не покажется. Гарантирую.

Куда то консультант не туда рулит. Работаиь будет конечно (ведь работало же такое 15 лет назад), но вы подумайте на счет него, я ведь то же из Торонто
Шутка.

[blanko27]

... А говорил новые технологии. С таким же успехом можно это сделать на TCP socket И где здесь выигрыш от применения xml?

А зачем им вообще использовать XML? У них же нет межплатформенного взаимодействия (Windows с UNIX-ом, там или Linux-ом) или фаервола посредине, между сервером и клаентом, можно сделать вообще через бинарный форматтер и ТСП транспорт - будет летать, как на самолете, безо всяких там, никому ненужных переводов в ХМЛ и обратно.

[Strannik223]

... А говорил новые технологии. С таким же успехом можно это сделать на TCP socket :) И где здесь выигрыш от применения xml?

А зачем им вообще использовать XML? У них же нет межплатформенного взаимодействия (Windows с UNIX-ом, там или Linux-ом) или фаервола посредине, между сервером и клаентом, можно сделать вообще через бинарный форматтер и ТСП транспорт - будет летать, как на самолете, безо всяких там, никому ненужных переводов в ХМЛ и обратно. :?

Хмм, один вариант когда есть смысл использовать SOAP даже в таком виде есть. Это если клиены за HTTP прокси могут сидеть.