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

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

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

Избегайте болтливых вызовов службы. Конечно, в двухуровневой системе лучше избегать «болтливых» обращений к базе данных, но при увеличении количества уровней вы будете платить за болтливые вызовы. Выберите отправку более крупных объектов. Например, если у вас есть таблица с несколькими поисками, отправка объекта по сети с предварительно найденными значениями часто сэкономит вам второй или третий вызов и не вызовет чрезмерной нагрузки на систему.

Надеюсь, эти идеи помогут.

Давайте посмотрим на это с точки зрения эволюции проектов разработки "корпоративного" программного обеспечения:

1. Начните с очень простого, хорошо организованного и, возможно, нового приложения с небольшими проблемами обслуживания (если вам повезет). Программисты могут быть недавними выпускниками, но система достаточно молода или чиста, чтобы они могли эффективно и быстро реагировать на запросы об изменениях. Большая часть кода базы данных может использовать хранимые процедуры. В работе не участвует DBA, нет формальной спецификации или дорожной карты.
2. Приложение растет. Часто возникает необходимость одновременной работы нескольких программистов над одними и теми же частями системы. Новые выпускники открывают контроль исходных текстов, чтобы помочь им разделить код между несколькими программистами, и отказываются от хранимых процедур в пользу n-уровневого дизайна или ORM, чтобы облегчить версионирование кода базы данных. Это хорошо работает до тех пор, пока каждая отдельная функциональная область достаточно изолирована. Теперь DBA может начать помогать настраивать запросы. Спецификации все еще нет, но может появиться высокоуровневая дорожная карта или список пожеланий.
3. В конечном итоге это превращается во взаимосвязанную систему приложений, которая выросла органически, а не по замыслу. Запросы на изменения становятся сложными, так как изменения в одной области имеют тонкие эффекты в других. Чтобы решить эту проблему, когда несколько приложений обращаются к одной базе данных и должны совместно использовать общую и сложную бизнес-логику, программисты обращаются к сервис-ориентированной архитектуре (веб-сервисы). Старые данные и бизнес-уровни анализируются, объединяются и рефакторятся в общий набор веб-сервисов. Большинство программистов теперь даже не знают, как подключиться к своей базе данных - это разрешено только тем, кто работает над основными сервисами, и даже они, как правило, оставляют любой реальный SQL команде DBA. Если модульное тестирование еще не используется, то теперь оно обнаруживается как часть настройки системы непрерывной интеграции или трекера проблем.
4. Система продолжает расти, но бизнес растет еще быстрее. Все в целом работает; качество хорошее, производительность не очень высокая, но все же приемлемая. Сейчас определенно есть спецификация и трекер проблем; на самом деле, невозможно сделать что-либо, что сначала не было бы связано с номером отслеживания. Проблема в том, что скорость изменений слишком медленная. Слои процессов между программистами и приложением не позволяют им идти в ногу с бизнесом экономически эффективным способом. Кто-то открывает для себя agile-методы.
5. Возвращаемся к первому шагу.

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

Тем не менее, возможно, что в итоге все складывается в слои, где у вас есть сервисы сырых данных, которые являются частными для определенных частей бизнеса, а эти "сырые" сервисы, в свою очередь, используются для создания нисходящих сервисов, которые составляют слой бизнес-правил. Трудно сказать наверняка, чем на самом деле занимается бизнес. Однако у меня есть ощущение, что такой уровень разобщенности встречается реже.

Я бы не рекомендовал этого делать, пока вы не перейдете на WCF. В противном случае вы будете передавать все свои данные туда и обратно в текстовом XML через HTTP, что существенно замедлит работу. У вас также будет очень мало выбора в отношении безопасности, поскольку для шифрования используется только SSL.

WCF позволит вам отправлять двоичные данные через TCP / IP, именованные каналы или очереди сообщений и даст вам большую гибкость с точки зрения безопасности.