Оба дизайна (приложение для веб-службы для БД; приложение для БД через DAL) довольно стандартны. Веб-сервисы часто используются при взаимодействии с клиентами для стандартизации семантики доступа к данным. Веб-сервис обычно способен более точно представлять семантику вашей модели данных, чем основное хранилище постоянных данных, и, таким образом, помогает поддерживать работоспособность системы путем абстрагирования и инкапсуляции проблем, связанных с IO. Веб-службы также служат дополнительной целью предоставления открытого интерфейса (хотя «общедоступный» может по-прежнему означать внутренний для вашей компании) ваших данных через протокол, который обычно доступен через брандмауэры. При использовании DAL для прямого подключения к БД можно инкапсулировать проблемы ввода-вывода данных аналогичным образом, но в конечном итоге ваш клиент должен иметь прямой доступ к базе данных. Ограничивая ввод-вывод четкой семантикой (обычно CRUD + Query), вы добавляете дополнительный уровень безопасности. Это не такая уж большая проблема для вас, так как вы запускаете веб-приложение - весь доступ к БД уже сделан из надежного кода. Однако веб-служба обеспечивает повышение устойчивости к внедрению SQL.
За исключением всех обоснований веб-сервиса, реальные вопросы:
Сколько будет использоваться The / веб-сервис / формат базы данных сайта налагает несколько более высокую нагрузку на веб-сервере - если сайт забивают, вы хотите рассмотреть долго и упорно, прежде чем положить другой Сервис на одной машине. В противном случае добавленная небольшая неэффективность, вероятно, не имеет большого значения. С другой стороны, если сайт забивается, вам, вероятно, все равно нужно горизонтально масштабировать, и вы сможете одновременно масштабировать веб-сервис.
Сколько вы получаете? Одной из основных причин наличия веб-службы является обеспечение доступности данных для клиентского кода, особенно когда требуется поддержка нескольких возможных версий приложения. Поскольку ваше веб-приложение является единственным клиентом, использующим веб-сервис, это не проблема - вероятно, на самом деле меньше усилий для самостоятельной версии приложения.
Вы хотите расширить? Вы говорите, что он, вероятно, никогда не будет использоваться ни одним клиентом, кроме одного веб-приложения, но эти вещи могут увеличиваться в размерах. Если есть вероятность того, что ваше веб-приложение может расшириться в масштабах или популярности, рассмотрите веб-сервис. Разрабатывая веб-сервис, вы уже нацеливаетесь на модульное решение с несколькими хостами, поэтому ваше приложение, вероятно, будет масштабироваться с меньшими трудностями роста.
Если вы не догадались, я фанат веб-сервиса. Но вышеизложенное также является моим честным (хотя и несколько предвзятым) мнением по этому вопросу. Если вы идете по пути веб-службы, обязательно сделайте его простым - сохраните логику приложения в приложении и логику службы в службе и постарайтесь провести яркую линию между ними при их расширении. Разработайте свой сервис для повышения эффективности и настройте хостинг так, чтобы он работал как можно более плавно.