Веб-служба или DLL?

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

Моя первоначальная мысль - создать DLL, инкапсулирующую всю необходимую функциональность, а затем вызвать ее через интерфейс Web Forms для ручного выполнения и консольное приложение, выполняемое как автоматическая (ежедневная) запланированная задача.

Другое предложение заключалось в том, чтобы вместо этого использовать веб-службу для основной функциональности, но поскольку приложение никогда не понадобится вызывать внешним ресурсом, я думаю, что дополнительные усилия, необходимые для внедрения веб-службы, могут не стоить проблем. Решение DLL также должно быть значительно быстрее (?).

Мой вопрос, какой маршрут вы бы выбрали? Есть ли какие-либо плюсы/минусы, которые я не рассматривал? Любые вопиющие упущения?

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

Ответ 1

Лично я говорю, иди в DLL. Это будет быстро и просто.

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

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

Наконец, если вам понадобится веб-служба на более поздний срок, вы должны иметь возможность довольно легко преобразовать DLL в веб-службу с минимальной доработкой.

Ответ 2

В настоящий момент существует нет необходимость создания веб-сервиса. Вам просто нужно будет поддерживать другую службу IIS на вашем сервере. Если позже вы создадите какой-то интерфейс, который понадобится для этой DLL, вы можете просто обратиться к нему. Поэтому нет необходимости делать это превентивным.

Ответ 3

Вы правы, веб-сервисы - это много хлопот по опыту и намного медленнее. Я предлагаю - сделать PONO (простой старый .net-объект), но использовать интерфейсы. Посмотрите в Spring.NET framework - он может экспортировать этот объект для вас как любой тип (веб-сервиса), поэтому вам не нужно делать это. На стороне клиента вы также можете использовать spring для выполнения инъекции зависимостей и решить, хотите ли вы встраивать DLL или веб-службу в процессе, просто изменив значение в файле конфигурации. Кроме того, spring имеет интеграцию с планировщиком Quartz, вы можете также изучить его.

Ответ 4

Использование DLL - это правильный путь, он быстрее и обеспечивает свободу в будущем для создания webservice с использованием этих DLL (если требуется) с большей защитой над webservice.

Ответ 5

Лично я сделал бы то, что вы сказали; поместите мою логику в DLL. Затем используйте DLL из вашего приложения, webservice и того, что еще предстоит определить интерфейс, который они запрашивают в будущем.

Ответ 6

Нам действительно нужна дополнительная информация. Его трудно ответить, зная, что именно вы предъявляете. Многоуровневый подход (dll/отдельный класс) прост и быстр. Многоуровневый подход (веб-сервис) позволит вам создать одну среду и даст вам больше абстракции. Вы можете изменить код, расположенный за веб-сервисом, без изменения ваших клиентов.

Но для того, чтобы оценить это, нам нужно знать, что ваш проект - это то, что эта DLL будет делать. В противном случае вы просто слышите предпочтения людей.

Ответ 7

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

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

Ответ 8

Я разрабатываю аналогичное приложение. принятый подход - это иметь мою логику извлечения в dll's. это открывается через веб-сервис. Я нахожу веб-сервисы проще, так как мне не нужно удалять интерфейсы или выставлять мои объекты (я использую классы для инкапсуляции данных) на клиенте. Затем у меня есть разработчики веб-сайтов и разработчики winform, которые создают собственный уровень представления. в то время как есть плюсы и минусы (не входят в них), веб-службы проще, поскольку у меня есть один слой. используя удаленный доступ, мне нужен дополнительный интерфейс или библиотека на стороне клиента, которая должна быть установлена на каждом клиенте. таким образом, я управляю только серверной стороной, в то время как разные GUI являются независимыми. я точно так же, как слабоватое связанное кодирование. мы запускаем многочисленные службы Windows, которые также используют веб-службы. наша компания является кредитной карточкой, и мы взаимодействуем с многочисленными системами. веб-сервисы обеспечивают максимальную гибкость.

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

Ответ 9

Ничего себе вау. Они все разделяют одну БД? Если это случай, нет, нет и нет. Если БД НЕ является общим, то это определенно DLL.

Правильный выбор - веб-сервис. Причина очень проста.

1) Согласованность модели домена и бизнес-логики. Допустим, вы сохранили перечисление в столбце, и вы добавили перечисление и развернули его в одно приложение. Теперь он нарушит два других приложения.

2) Простота развертывания. Одно изменение = одно развертывание. Если это dll, одно изменение = 3 развертывается.

3) транзакции DB и управление concurrency. Гораздо проще разрешить его в одном домене приложения.

Что касается недостатков, предлагаемых другими, я считаю их слишком частичными.

1) Сложность при отладке через домен приложения. Вы должны опубликовать возможные исключения через WSDL как исключения ошибок. Вызывающий клиент должен соответствующим образом обрабатывать эти исключения ошибок. Также невероятно просто настроить модульные тесты и макеты как для вызывающего клиента, так и для сервера. Точка останова - это не правильный способ отладки и работы с распределенными приложениями. Вы можете, и это не сложно. Я просто не верю, что правильный подход.

2) Производительность. WCF позволяет вам устанавливать различные привязки через конфигурацию. От базового http (который легче отлаживать) вплоть до именованного канала, который вы можете использовать для получения производительности, близкой к локальной. Это решение может (почти. Есть несколько причуд с другой привязкой, которые необходимо учитывать.) Также следует решить после разработки.

3) Безопасность. Говорить, что WCF не справляется с безопасностью, это смешно неправильно.

Наконец, реальные минусы от меня:

1) Более сложный. Согласовано. Разный контекст затрудняет разработку приложения. Это происходит двумя способами. Эта сложность обеспечивает четкое разделение уровней. Контекст презентации должен оставаться там, где они есть, на уровне презентации.

2) Требовать больше планирования. Конструирование контрактов для веб-служб WCF - это само по себе.

3) Накладные расходы на управление для конфигурации. Может быть сложной для новых разработчиков, но я надеюсь, что вы сможете преодолеть это препятствие быстро. Конфигурация WCF - это обоюдоострый меч, мощный, но сложный (для некоторых).

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

Итак, каково было ваше окончательное решение? Прошло уже четыре года.

Ответ 10

Я не могу поверить, что принятый ответ был тем, кто советовал вам использовать DLL...

"мы не представляем, как что-то меняется какое-то время".

Вот почему нам приходится тратить время на устранение проблем, создаваемых разработчиками, принимающими эти решения. Не думайте о сегодняшнем дне, подумайте о завтрашнем дне. Материал базы данных должен быть скрыт от клиента, что делать, если вам нужно добавить нового клиента, а завтра новый? Стройте надлежащие контракты и используйте сервисы, сети или нет.