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

Question

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

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

Answer 6

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

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

Answer 7

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

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

Answer 8

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

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

Answer 9

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Answer 10

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

«мы ничего меняющегося в течение некоторого времени не предусматриваем.»

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