замена сборки и наследование классов

Question

Служба WCF с именем Portal.WebServices.TaskListService использует файл кодовой привязки TaskListService.svc.cs.В этом файле объявите тип с именем TaskListService, который наследуется от типа TaskListServiceBase.и реализует интерфейс с именем ITaskListService.Итак:

TaskListService: TaskListServiceBase, ITaskListService

   ^                     ^                  ^   
   |                     |                  |
 application               separate assembly 

Я хочу развернуть TaskListService Once на веб-сервере и поместить TaskListServiceBase и интерфейс в отдельную сборку , на которую ссылаютсяприложением, в котором находится TaskListService.Поэтому, когда я хочу добавить, удалить или обновить функциональность в веб-службе, мне нужно только скопировать новую сборку в папку bin приложения.

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

В общем, мой вопрос: Я хочу обновить функциональность службы WCF без повторного развертывания всего приложения, только обновленной сборки

^{(да, я чувствую себя немного глупо здесь}

Answer 1

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

Что касается развертывания, вы можете сделать это, так как сборки копируются в тени IIS. Однако, как только новая сборка будет скопирована, я предполагаю, что вам придется перезапустить приложение, чтобы загрузить новую сборку.

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

Answer 2

Это практика, которой я следую, я не знаю никаких минусов, только выгоды.Я делаю еще один шаг вперед, потому что я не использую код позади.Таким образом, в приведенном выше примере TaskListService.cs будет находиться в сборке ServiceImplementations, отдельно от сборки ServiceContracts.

Это позволяет вам разбить ваши контракты / реализации на несколько сборок, если необходимо (возможно, разделенных по доменам) и обновлять их независимо.