Где находятся службы данных WCF и ADO.Net?

Question

Я немного смущен службами данных ADO.Net.

Предназначен ли он только для создания веб-сервисов RESTful?Я знаю, что WCF зародился в мире SOAP, но теперь я слышал, что у него хорошая поддержка REST.То же самое касается служб данных ADO.Net, где вы можете заставить их работать в модели RPC, если вы не можете смотреть на все с точки зрения ресурсов.

По крайней мере, из недавно просмотренных демонстраций видно, что службы данных ADO.Net построены на базе стека WCF на сервере.Пожалуйста, поправьте меня, если я ошибаюсь.

Я не собираюсь начинать дебаты о REST и SOAP, но думаю, что все уже не так кристально ясно.

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

Answer 1

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

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

WCF 3.5 до SP1 была довольно слабой платформой RESTful, с SP1 ситуация улучшилась как в шаблонах Uri, так и благодаря доступности поддержки ATOMPub, так что она становится более функциональной, но на самом деле они не предоставляют какого-либо элегантного решения для поддержки, скажем, JSON. , XML, ATOM или даже что-то более эзотерическое, например, полезная нагрузка, такая как CSV одновременно, за исключением необходимости использовать перезапись URL-адресов и другое расширение, изменение имен методов и т. д.- вместо того, чтобы просто выбирать сериализатор/десериализатор на основе заголовков запроса.

С помощью WCF по-прежнему сложно создавать сервисы, которые работают более естественно и спокойно, т.е.где ресурсы включают URL-адреса, и вы можете переходить между состояниями, перемещаясь по ним - это немного неуклюже - службы данных ADO.Net делают это довольно хорошо благодаря поддержке AtomPub.

Я бы порекомендовал использовать веб-службы там, где они, естественно, являются службами и соблюдаются строгие границы служб, использовать службы данных ADO.Net для клиентов с богатым веб-стилем (веб-сайты, ajax, silverlight), где компонуемость URL-запросов может сэкономить много сантехники, и ваша доменная модель довольно проста...и разверните свой собственный уровень REST (возможно, используя структуру MVC в качестве отправной точки), если вам нужен полный контроль над информацией, т.е.если вы публикуете API, который другие разработчики могут использовать на социальной платформе и т. д.

Моя 2ø стоит!

Answer 2

Использование привязки rest WCF очень удобно при работе с кодом, который вообще не взаимодействует с базой данных.Глаголы HTTP не всегда должны противоречить поставщику данных.

Answer 3

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

Глянь сюда: