Веб-сервис или DLL?

Question

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

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

"мы не предвидим, что что-то изменится в течение некоторого времени."

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

Answer 6

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

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

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

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

3) Транзакции БД и контроль параллелизма. Намного проще решить эту проблему в одном домене приложения.

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

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

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

3) Безопасность. Сказать, что WCF не занимается безопасностью, - это смешно.

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

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

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

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

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

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

Answer 7

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

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

Answer 8

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

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

Answer 9

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

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

Answer 10

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