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

Question

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

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

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

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

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

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

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

Answer 3

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

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

Answer 4

Я бы сказал, что использование Варианта 1 будет проще и проще, тем более что вам просто придется потратить дополнительное время на ограничение доступности REST. (каламбур!)