В отношении приложения, имеющего как версию веб-клиента, так и рабочего стола:
Какова наилучшая практика для настольного клиента, которому необходим доступ к SQL Server?
Если вы используете локальный SQL Server, напрямую обращайтесь к базе данных. Если клиент должен использовать базу данных SQL в другой системе, использование веб-службы предпочтительнее для дополнительной защиты и дополнительного преимущества наличия бизнес-уровня, который должен иметь возможность обрабатывать несколько пользователей.
Каковы преимущества подключения к базе данных из приложения и использования веб-службы?
Подключение через веб-службу всегда будет немного медленнее, и изменения в базе данных будут немного сложнее добавить во всю систему. (В принципе, это означало бы, что вам нужно создать более новую версию веб-службы при сохранении старой веб-службы для обратной совместимости.)
Какой из них обеспечивает лучшую безопасность?
Использование веб-служб имеет тенденцию быть более безопасным, хотя безопасность часто является проблемой людей, чем проблема с программным обеспечением. Но с веб-службой между пользователем и базой данных соединение с базой данных более безопасно, так как пользователь не может напрямую обращаться к нему. (За исключением функций, которые вы предоставляете через веб-службу.) Этот момент является спорным, когда клиент и база данных находятся в одной системе, потому что тогда пользователь может получить полный доступ.
Какой тип области вызовет одно и другое (корпоративная интрасеть против веб-приложения и т.д.)
Веб-службы лучше подходят для клиент-серверных приложений, где пользователи не должны иметь прямой доступ к базе данных. В противном случае прямое соединение с базой данных просто улучшит производительность. При создании веб-службы начните с написания общей (классной) библиотеки, которая обеспечит функциональность веб-службы. Создайте веб-сервис вокруг этой (бизнес-) библиотеки, подвергая важные методы внешнему миру. Любой веб-сайт может напрямую обращаться к этой библиотеке без использования веб-службы, хотя вы всегда можете выбрать, чтобы даже код веб-сайта получал доступ к данным через веб-службу. Даже если вы создаете только настольное приложение с локальной базой данных, писать бизнес-библиотеку с логикой для доступа к базе данных - это очень хорошая вещь. Ваш клиент может позвонить в эту бизнес-библиотеку напрямую или через веб-службу в зависимости от ваших потребностей.
Есть ли какие-либо другие соображения, которые необходимы при выборе на платформе?
В основном просто количество аппаратного обеспечения, которое вы готовы использовать для настройки. Если вы можете позволить себе создать сервер базы данных, отдельный веб-сервис для служб и третий для своего веб-сайта, с дюжиной или около того клиентских систем, то вы можете выбрать самую многоуровневую версию, где и клиент, и веб-сайт вызовите веб-службу, которая вызывает базу данных. Но если все нужно запустить в одной системе, тогда просто придерживайтесь приложения и бизнес-уровня/библиотеки.
Добавление слоев снижает производительность с точки зрения одного пользователя. Однако работа с несколькими уровнями может повысить общую производительность, поскольку ресурсы становятся лучше распределены между несколькими пользователями.
Общее эмпирическое правило:
Я бы сохранил это просто и минимизировал количество слоев. Слои оценивают стоимость, вводят сложность и требуют внесения изменений в другие места.
Итак, если соединение netwerk между приложением и сервером Sql открыто (обычно tcp-порт 1433), я бы использовал Sql-подключение.
Если вы можете получить доступ к БД с рабочего стола, тогда вы должны это сделать.
У вас несколько клиентов. Это означает, что ваше приложение должно иметь многослойные слои. Это не означает, что вам нужно несколько уровней.
Несколько уровней могут потребоваться, если ваши слои должны передавать данные по брандмауэрам или если у вас есть различные технологии.
Учитывая контекст, может возникнуть серьезная проблема безопасности при доступе клиентов к базам данных. Это требует либо предоставления пользователям доступа к db, либо создания учетной записи службы. Предоставление пользователям прямого доступа к db создает риски. Оба подхода открывают дверь для использования dll для подключения к db вне контекста приложения (несколько раз я видел случаи, когда есть общий класс доступа к данным, который используют все функциональные операции. И, конечно же, эти компоненты инициализируют всю информацию о соединении. Доступ на основе отражения позволяет легко получить защищенные или частные методы, если вы не утверждаете привилегии безопасности).
Веб-службы предоставляют функциональные операции, которые не предоставляют никаких операций на основе sql. Это не только безопаснее, но и абстрагирует клиента от реализации хранилища данных.
Опять же, это зависит от вашего контекста. Однако в сфере Enterprise/ISV это, как правило, большой нет-нет.