Wcf Service Proxy Name / Стратегия именования пространств имен - PullRequest
Новая
       14

Wcf Service Proxy Name / Стратегия именования пространств имен

4 голосов
/ 29 мая 2009

У кого-нибудь есть стратегия именования, которая хорошо работает для прокси-классов служб?

Например, если мне предоставят три веб-сервиса в двух проектах следующим образом: 

XWs
  AService.asmx
YWs
  BService.svc
  CService.svc

Что будет использоваться в качестве справочного имени службы и пространства имен для AService, BService и CService?

В общем, я хотел бы, чтобы что-то в имени / пространстве имен прокси-сервера указывало, что используемая вещь не является конкретным классом, а представляет собой прокси-сервер - и то, и другое не противоречит использованию конкретных классов [и принудительному использованию псевдонимы или имена классов, соответствующие пространству имен], и поэтому мы не скрываем тот факт, что происходит скачок (я предполагаю, что суффикс Client's по умолчанию генератора Wcf Service Proxy покрывает это). Также важно то, что он имеет дело со случаями, когда кто-то пишет сервис-оболочку / шим, который перенаправляет [под] набор вызовов в другой сервис, на который ссылаются.

Я использовал разные стили (добавляя Ws, ServiceProxy, Ref или Proxy суффиксы? Префикс ServiceName.), но никогда не был полностью им доволен.

Что сработало для вас? В каких руководствах по стилю упоминается стиль именования?

Редактировать: Хотя ответ Чизо охватывает большую часть моего вопроса, мне все еще интересно услышать ответы по:

  1. Стратегия для прокси-классов пространства имен, как в примере выше
  2. Руководство по стилю, в котором упоминается стратегия именования прокси

Ответы [ 2 ]

2 голосов
/ 29 мая 2009

Первоначально я использовал такие имена, как ServiceName Proxy и ServiceName SvcProxy . Но, как и вы, я не был особенно доволен этими именами, и в результате я не придерживался их. Теперь я просто прибегаю к ServiceName Service или ServiceName Svc .

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

С соглашением об именах, я думаю, вы пытаетесь указать, что прокси-класс взаимодействует с удаленной службой. (Когда мы называем это «прокси», мы имеем в виду, что он стоит перед чем-то, в данном случае это удаленный сервис.) Если это так, то почему бы не ServiceName Service или ServiceName Соединение , или по аналогии? Например, System.Data.OleDb.OleDbConnection или System.Data.SqlClient.SqlConnection.

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

1 голос
/ 12 марта 2010

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

Так, например, это: 

companyname.services.contracts.service1contract
companyname.services.service1

или это: 

companyname.services.service1
companyname.services.service1contract
...