Действительно ли плохая идея использовать веб-сервисы для обертывания слоя доступа к данным?

Question

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

Может ли кто-нибудь предоставить примеры использования веб-сервисов для переноса слоя доступа к данным - плохая идея?

Answer 1

В зависимости от того, что вы определяете как «уровень доступа к данным», может быть или не быть веской причины для этого. Традиционно распределенные API, такие как веб-сервисы или уровни RPC, живут на следующем уровне вверх. Это имеет следующие преимущества:

1. Без жесткой связи с БД. Этот уровень можно настроить для удобной игры с распределенным доступом - например, для организации API-интерфейса с целью минимизации циклов.

2. Вы можете добавить дополнительный уровень проверки API. Уровень доступа к необработанным данным может разрешить запись неверных данных в систему. По этой причине было бы плохо выставлять его ненадежным клиентам.

3. Вы можете установить безопасность на уровне приложений для уровня служб таким образом, чтобы это было невозможно для уровня доступа к данным.

4. Пункты 1 и 2 означают, что вы получаете повторное использование проверок бизнес-правил на промежуточном уровне.

Предоставление простого API для операций CRUD также может быть достигнуто путем прямого подключения к серверу базы данных, поэтому уровень веб-службы поверх этого не даст вам ничего, что СУБД уже не предоставляет. Некоторые механизмы БД также могут напрямую обслуживать запросы через HTTP, поэтому вы можете туннелировать их через большинство брандмауэров. Тем не менее, аспекты безопасности означают, что вы почти наверняка не хотите показывать это в общедоступном Интернете.

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

Answer 2

Главный толчок в современном мире - это облачные или SaaS-вычисления.

Учитывая это, многие крупные приложения, в том числе SalesForce (CRM), Google, Parature (helpdesk) и т. Д., Предоставляют свои приложения через веб-сервисы.

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

Тем не менее, единственный пример, который я могу вспомнить при использовании веб-сервисов для переноса вашего DAL, - это плохая идея, когда только одно приложение будет вызывать DAL и находится под вашим непосредственным контролем разработки. Это связано с потерей производительности, выплачиваемой за сериализацию / десериализацию данных через границы веб-службы.

Answer 3

В .NET WCF предлагает способ обойти производительность, о которой упоминает Крис. WCF должен позволять запускать ваш компонент доступа к данным для вашего собственного приложения, но также быть легко доступным как веб-сервис. (Отказ от ответственности: я на самом деле не реализовал это, просто посмотрел на это.)

Answer 4

Что ж, если вы выставляете весь API через веб-сервис без защиты, это может быть плохой идеей.

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

Если вам когда-нибудь понадобится убедить руководство, помните, что "Google делает это".