Народ, такой вот вопросик. По долгу службы необходимо писать веб-сервисы для работы с БД. Как бы понятно, что веб-сервисы являются новым уровнем взаимодействия клиент<--->БД. Вот тока вопрос, каким образом это звено реализовывать.
С начала для каждой сущности БД я описывал соответствующие классы и использовал их объекты как на стороне клиента, так и на стороне сервиса. Но больно муторно стало с заполнениями атрибутов объектов.
Потом, почитав МСДН, где мелкософтные утверждают, что для работы сервисов и БД просто шикарно использовать DataSet. Я попробовал... Да, удобно. Особенно получение данных и отправка их клиенту. Но, получается, что для работы с полученным DataSet-ом, клиенту необходимо знать структуру БД, да и может прийти служебная информация, которая совершенно не нужна клиенту. Кроме того, смысл использования использования вебсервиса, как отдельного уровня напрочь отпадает. Ну разве только, что использование для передачи данных HTTP.

Давайте пофилософствуем на эту тему. Какие еще способы есть? У кого какой опыт работы в этом направлении?

Цитата

Но, получается, что для работы с полученным DataSet-ом, клиенту необходимо знать структуру БД

А ты пишешь универсальный клмент для любой базы?
А чтоб получать нужную информацию надо использовать запрос в адаптере а потом заполнять.
Извини если не понял суть проблемы

Вообще-то я слышал, что существуют такие утилитки, с помощью которых можно генерировать набор классов для определенной базы данных. То есть примерно то, что ты делал вначале, только не вручную, а автоматически. Ну, естественно, классы получаются удобными в использовании, поддерживаются все фичи ADO.NET, и т.д.
Но опять же этот набор классов должен быть как у клиента, так и у сервера, то есть и клиент и сервер должен знать структуру БД. Хотя если честно, я не вижу здесь никакой проблемы, если конечно клиент не должен быть универсальным, что вряд ли, как я понял из твоего сообщения.

Цитата(Tomcat @ 21.7.2004, 19:02)

Я попробовал... Да, удобно. Особенно получение данных и отправка их клиенту. Но, получается, что для работы с полученным DataSet-ом, клиенту необходимо знать структуру БД, да и может прийти служебная информация, которая совершенно не нужна клиенту. Кроме того, смысл использования использования вебсервиса, как отдельного уровня напрочь отпадает. Ну разве только, что использование для передачи данных HTTP. Давайте пофилософствуем на эту тему. Какие еще способы есть? У кого какой опыт работы в этом направлении?

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

Немного не понимаю, в чем проблема, если клиент содержит метаданные о маппинге свойств бизнес-объектов в поля БД? Просто организовать это можно следующим образом:

Клиент дергает веб-метод (он знает, что он хочет получить, и знает, как из датасета сделать те объекты, которые ему нужны).
Веб-сервис отдает датасет
Клиент превращает его в то, что ему нужно.

В чем проблема?

Спасибо, что откликнулись....

to Borisff2003: Спасибо, но я знаю как работать с ADO.NET.

to [Last]Wizard: Использование сервиса подразумевает его описание. Так что клиент, естественно, будет знать структуру классов. А вот про эти утилитки не мог поподробней. Где их можно посмотреть?

to arilou: По аналогии с Borisff2003, я знаю, что такое Web-сервисы. В твоем решении мне не нравится то, что сервис используется только как транспорт данных. Получается, что к описанию сервиса необходимо прилагать и описание структуры БД. Мне кажется это не к чему. Получается, что любой сервис, предназначенный для работы с БД, можно реализовать только 3-4 методами. Суть которых заключается в получении строкого запроса к БД и возвращение соответствующего ДатаСета.

Сервис у меня не универсальный. Строится под конкретную задачу. Как я понимаю суть веб-сервисов, он должен быть устроен таким образом, чтобы несколько абстрагировать устройство БД. То есть, например, если две сущности БД связаны какким-либо отношением, то клиенту должно быть совершенно все равно, каким способом это отношение реализовано в самой базе. Ему важны возвращаемые объекты и взаимосвязь между этими объектами.
Использование же ДатаСета подразумевает знание внутреннего устройства БД. Исключение составляет тот случай, когда ДатаСет заполняешь сам, а не при помощи адаптера, но это глупо. А еще ДатаСет со своими таблицами и строками ориентированам на реляционную модель данных.
Вот чем мне не нравится использование ДатаСета сервисами.

Tomcat, насчет утилитки.

Посмотри на http://www.llblgen.com/defaultgeneric.aspx.

Там можно скачать демку (14 дней работы). Насчет кряка не знаю, не искал.

Цитата(Tomcat @ 23.7.2004, 09:45)

В твоем решении мне не нравится то, что сервис используется только как транспорт данных. Получается, что к описанию сервиса необходимо прилагать и описание структуры БД. Мне кажется это не к чему. Получается, что любой сервис, предназначенный для работы с БД, можно реализовать только 3-4 методами. Суть которых заключается в получении строкого запроса к БД и возвращение соответствующего ДатаСета. Использование же ДатаСета подразумевает знание внутреннего устройства БД. Исключение составляет тот случай, когда ДатаСет заполняешь сам, а не при помощи адаптера, но это глупо. А еще ДатаСет со своими таблицами и строками ориентированам на реляционную модель данных. Вот чем мне не нравится использование ДатаСета сервисами.

Наверное, я не до конца раскрыл свою мысль - руки за головой не успевают Постараюсь остановиться и изложить поподробнее.

Почему я предлагаю использовать датасеты (или какие-нить другие DTO) для передачи информации (а не данных!) между клиентом и сервисом?
Бизнес-объекты, как правило, это сложные сущности, существующие не по отдельности, а в некоем графе взаимосвязей. Как правило, они хранятся в реляционной БД и существует в приложении некоторый механизм, т.н. object-relational mapper, который вместе с ADO.NET отвечает за хранение и загрузку данных. Этот мех-м реализует загрузку объектов по требованию (например, lazy load, когда загружается только самая необходимая часть от бизнес-объекта, и greedy load, когда грузится все, что нужно для выполнения какой-либо операции, и т.д.).
При разделении архитектуры на хотя бы 2 уровня возникает необходимость обмена информацией между ними. Тут на помощь приходят датасеты (или их составные части - datatable, datarow, data... и т.д.), потому что они по умолчанию поддерживают сериализацию, не требуя от программиста дополнительных усилий. Что касается бизнес-объектов, то они могут жить и на сервере, и на клиенте (мы все это знаем), и они не знают ничего о стр-ре БД, это знает mapper.

Так вот, конечно же, использование сервисов не ограничивается доставкой данных. Допустим, есть сервис, выполняющий какую-либо операцию над двумя бизнес-объектами. На клиенте (как, в прочем, и на сервере) создаются экземляры mapper'ов, отвечающие за преобразование объектов в реляционные данные. Клиент вызывает веб-метод, передавая ему, например, 1 датасет, содержащий инфу об обоих объектах. Веб-метод создает у себя экземпляры бизнес-объектов, выполняет над ними операцию, и возвращает датасет с измененными данными обратно клиенту, который преобразует его обратно в объекты. Заметь, что никто напрямую не знает о БД, а реализуется это через посредника - mapper'а.

Почему не выгодно напрямую оперировать с бизнес-объектами? Хотя бы, потому что каждое обращение к ссылке на другой объект может потребовать вызова сервиса данных, выполнение которого потребует обращения к серверу, что закончится снижением производительности. Опять же, веб-сервисы - это stateless-операции, по крайней мере, без наличия Web Service Extensions.

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

arilou, насколько я понял из твоего ответа - ты предлагаешь не отказываться от бизнесс-объектов, наоборот, использовать их для реализации логики работы программы, а датасет использовать только для передачи информации между уровнями. Такой подход в приципе понятен, но есть несколько "но":

Во-первых, создавать руками классы - бизнесс-объекты, довольно сложное и мутороное занятие (если конечно в БД больше 5-10 таблиц).

Во-вторых необходимо реализовать маппинг (в обе стороны) - тоже дело не простое.

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

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

В конечном итоге - какой подход выбрать - личное дело каждого.

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

Цитата(Tomcat @ 23.7.2004, 16:41)

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

Естественно, если приложение изначально не проектировалось с использованием доменной логики, или если кол-во бизнес-объектов не превышает 5, или нет сложных взаимосвязей между ними, то прикручивать то, что я описал, не имеет смысла. А вот если сразу это все учитывать, то ... :-)
И вообще, есть такая книжка "Patterns of Enterprise Application Architecture" by Martin Fowler. При наличии желания ее можно найти в PDF или CHM. Если не найдете, пишите мне, я пришлю.

Цитата(arilou @ 23.7.2004, 16:54)

Цитата(Tomcat @ 23.7.2004, 16:41) Мне, в принципе, подход с генеренными классами больше нравится. Получается, что клиент использует веб-сервис, как библиотеку классов, решаемую очень узкую задачу. Естественно, если приложение изначально не проектировалось с использованием доменной логики, или если кол-во бизнес-объектов не превышает 5, или нет сложных взаимосвязей между ними, то прикручивать то, что я описал, не имеет смысла. А вот если сразу это все учитывать, то ... :-) И вообще, есть такая книжка "Patterns of Enterprise Application Architecture" by Martin Fowler. При наличии желания ее можно найти в PDF или CHM. Если не найдете, пишите мне, я пришлю.

Может быть этот вопрос чайника. Может чего не соображаю, но...
В общем, ладно, использовать DataSet в web-сервисах - весело, круто, удобно. Но одной из главных черт использования сервисов является возможность создания распределенных приложений в независимости от платформ на которых разрабатываются и работают состовные части системы (умных словей знаю мало, но по-моему это называется гетероморфностью). Если и сервис, и клиент разрабатываются под .NET, то понятно, и тот и другой могут использовать всю мощь DataSet-а. А вот как быть, если клиенты будут реализовываться на других вещах, например то же JAX-RPC в Java. В случае использования сгенерированных или своими руками созданных классов, тот же JAX-RPC нагенерит клиентских заглушек, соответствующих этим классам. А вот если возвращается DataSet, я затрудняюсь сказать, что он там создаст. Данные-то, клиент в конечном итоге получит, но вот с их апдейтом будут, скорее всего, проблемы.

Как быть здесь?

P.S. Я честно скажу, в своих словах я не уверен. Читайте первые два предложения. Но мой опыт мне подсказывает так.

Цитата(Tomcat @ 29.7.2004, 10:16)

А вот если возвращается DataSet, я затрудняюсь сказать, что он там создаст. Данные-то, клиент в конечном итоге получит, но вот с их апдейтом будут, скорее всего, проблемы. Как быть здесь?

Знаешь, скорее всего ты прав. Я не имею своего опыта разработки веб-сервисов на других платформах, кроме .NET, но видел такаую ситуацию: веб-сервис, разработанный на PHP, используется из C#. Там была сложная структура данных, которая возвращалась веб-сервисом, и у C# были проблемы с ее распознаванием при генерировании proxy-классов.
Так что, я думаю, если задача стоит разработать сервер на Java, а клиента на C#, то скорее всего, придется использовать понятные для обоих объекты.
Повторюсь, что сам такого не делал.

Вопрос следующий: 
Как можно в c# сделать обращение к wsdl не добавляя web reference,  не генерируя абстрактных прокси классов и прочей приблуды типа mssoapclient.. 

Как реализовать это просто и красиво в C# в тремя строками как в 1с 

ОпределениеСервиса = Новый WSОпределения("http://mdtyphoon/websrvc1/websrvc1.1cws?wsdl");
 
ПроксиДляЗаписи = Новый WSПрокси(ОпределениеСервиса, "http://mdtyphoon/", "websrvc1", "websrvc1Soap");
 
результат = ПроксиДляЗаписи.GiveMeCurrentBalance(date);

Лично я тоже сомневаюсь, что получится апдейтить данные таким образом.
В своих проектах мы используем веб сервисы как адаптер между клиентом и БД, а DataSet'ы просто как удобный объект для инкапсуляции передаваемых данных.
Идея такая: клиент заполняет DataSet определенной (заранее установленной) структуры и отправляет сервису. Он его получает, парсит, обращается к БД, формирует DataSet с ответом, который не обязательно (да и не желательно) является прямой выгрузкой из БД и отправляет его клиенту.


Лишние данные абсолютно не обязательно возвращать. Можно делать селекты только нужных колонок, объеденять их, давать другие имена, которые будут понятны клиенту.