веб-сервис / wcf сервис, еще лучше возвратить набор данных?

Я думаю, что самая большая проблема с отправкой DataSet по сети, если предположить, что вы «владеете» обоими концами, - это огромный «вес», который несет DataSet - с его возможностями взаимодействия и т. Д. Он делает гораздо больше чем транспортные данные. Простая коллекция объектов должна быть значительно более легкой.

Если вы не «владеете» обеими сторонами или у вас могут быть другие клиенты, использующие вашу службу, то DataSet станет кошмаром для взаимодействия.

Если вы этого не сделаете. заботитесь о любой из этих проблем, и вы чувствуете, что набор объектов - это слишком много «работы» (например, если вы просто собираетесь перевести его обратно в DataSet на другом конце), тогда это ваш выбор.

хорошая статья по этому поводу здесь .

Единственный раз, когда я возвращаю DataTable / DataSet через WCF, это то место, где у меня есть что-то, где просто невозможно узнать схему заранее, или они просто не приносят никакой пользы. 99,99% времени я работаю с обычными классами DTO, так как это дает хорошее сочетание производительности, простоты (для отладки) и взаимодействия.

Я работаю с WCF со времен 3.0 CTP ... I ' Я использовал DataTable через WCF только пару раз ... Я чувствовал себя немного грязным по этому поводу, но в рассматриваемых случаях просто не было возврата инвестиций, если бы я делал это трудным путем.

Просто обратите внимание, что для клиента, не использующего .NET, будет очень их использовать.

Пользовательские объекты упрощают работу с вашими клиентами. DataSets / DataTables облегчают вам задачу.

Я думаю, что вы должны основывать свое решение на том, кому вы хотите облегчить задачу.

Подобные вопросы сложно решить, но в целом вы не хотите возвращать набор данных из веб-службы. Insead попытается вернуть бизнес-объект. Что-то, что имеет смысл для делового человека в качестве концепции, например, класса Order. Причина этого в том, что, как правило, вы не хотите связывать клиент веб-сервиса с деталями реализации приложения, предоставляющего сервис. Клиент заботится о заказах, а не о том, как эти заказы затем структурируются в базе данных. Это создаст тесную связь, которая противоречит духу веб-сервиса. Во-вторых, если клиент, использующий веб-сервис, не является клиентом .net, тогда они получат довольно неприятный XML для создания / синтаксического анализа с целью чтения / записи набора данных, который не был бы типом данных на их платформе.

Я бы не стал использовать наборы данных поверх веб-служб по следующим причинам (они могут иметь или не иметь отношения к вашему случаю):

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

Несмотря на популярность ORM, я возвращаю наборы данных. Возврат настраиваемых объектов означает большую работу по дублированию функциональности, уже присутствующей в классе набора данных. Наборы данных отлично справляются с представлением табличных данных в памяти.