Повторное использование на основе сервера - DLL, GAC или REST?

Question

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

До сих пор мы использовали простое повторное использование библиотеки DLL с функциональностью, ее конфигурационным файлом и зависимостями, развернутыми везде, где она используется.Поскольку любые изменения теперь приходится вносить в нескольких местах, этот метод является болезненным при создании новых версий функциональности или когда новые клиенты хотят его использовать.

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

1. Поместите библиотеку DLL (и зависимости) в GAC.Тогда возникает вопрос, как настроить компонент.Поскольку клиенты не заинтересованы в конфигурации, мы склоняемся к хранению конфигурационного файла по жестко заданному пути на сервере.

2. Опубликуйте функциональность как внутреннюю службу (на основе REST).Доступ к нему может быть ограничен внутренними клиентами, использующими брандмауэр.

На наш взгляд, плюсами # 1, по-видимому, являются производительность и, возможно, безопасность, в то время как # 2 можно рассматривать как более простую в настройке.

Мы упускаем здесь что-нибудь важное?Кто-нибудь бывал в подобной ситуации раньше и хочет поделиться некоторыми соображениями?

Answer 1

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

1. Поскольку все ваши клиенты совместно используют один двоичный файл, теперь потребуется, чтобы все ваши клиенты тестировались каждый раз, когда вы вносите в него изменения.Теперь я знаю, что в вашем конкретном случае вам, возможно, придется сделать это в любом случае, поскольку мы можем предположить, что вы будете изменять базу данных, которая находится за компонентом.
2. Не надо ничего жестко кодировать.Вы можете сохранить путь к своей конфигурации в разделе AppSettings в файле machine.config.

Что касается варианта 2, то одной из альтернатив было бы использование WCF (при условии, что ваша среда может его поддерживать).Используя WCF, вы могли бы затем использовать транспорт TCP с использованием двоичной серилизации (И может существовать транспорт с общей памятью).Оба эти варианта помогли бы сократить разрыв в производительности (хотя вариант 1 всегда будет превосходить подход, основанный на обслуживании).

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

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

Вариант 2 также позволяет вам масштабировать сервис в будущем, если вам когда-нибудь понадобится больше мощности процессора.

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

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

Answer 2

Как уже сказал Джош, к сожалению, ответ на подобные вопросы часто бывает "это зависит".

Я большой поклонник GAC, но вы должны помещать туда только тот код, в отношении которого вы уверены, что он работает (почти) идеально и не нуждается в частом обновлении.Пока фрагмент кода находится "в разработке", просто публикуйте его вместе с каждым приложением, которое его использует.

Answer 3

Я бы сказал, что использование варианта 1 было бы проще и понятнее, тем более что вам просто придется потратить дополнительное время, ограничивая доступность ОСТАЛЬНЫХ.(каламбур!)

Answer 4

Джош указывает на WCF как на вариант, и я бы, безусловно, поступил именно так.

Эта проблема - именно то, что SOA должна решить!