C # .net - Соглашения об именовании Dll в сценариях интерфейса / реализации - PullRequest
Новая
       33

C # .net - Соглашения об именовании Dll в сценариях интерфейса / реализации

2 голосов
/ 03 августа 2011

Мне нужны некоторые предложения для умного именования dll и / или подсказки, если существуют какие-либо соглашения об именах для следующего сценария.

У меня есть определение интерфейса и несколько типов, используемых этим определением интерфейса, инкапсулированных в одну DLL. Тогда у меня есть реализация этого интерфейса в другой DLL. «Особенным» в этой ситуации является то, что я не занимаюсь разработкой приложения, а скорее набором функций (он же фреймворк), который используется несколькими приложениями моей компании. Доступ к этим функциям осуществляется через определение его интерфейса через MEF, поэтому пользователь этой платформы обычно не знает, и это не важно для него, в какой реализации dll (поскольку ему нужно только знать и ссылаться на dll, содержащую определение интерфейса). ). Просто в действительно необычных случаях он может захотеть узнать, как названа dll (та, которая содержит реализацию), потому что он хочет заменить реализацию своей собственной.

Я создал некоторые требования для именования dll:

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

Во-первых, мне пришла в голову идея сгруппировать все определения интерфейсов определенного типа в одну dll, что создаст очень хорошо именованное пространство имен, поскольку я могу сгруппировать, например, все «сервисы» в dll под названием MyCompany.Services. dll, поместите все определения и типы в этот корень (который создает пространство имен MyCompany.Services), и, следовательно, сохранили структуру решения равной пространствам имен (что может быть обсуждено здесь, если это полезно или нет).

Но это порождает большую проблему:

Если я подписываю dll и что-то изменяю в моем MyCompany.Services.dll, я должен перекомпилировать все dll реализации, даже если это изменение затрагивает только одну из этих n dll. В этот момент я подумал о том, чтобы поместить каждое определение интерфейса и типы типов в собственную dll (как описано в начале этого поста).

1 Ответ

0 голосов
/ 03 августа 2011

Мои 2 цента стоят:

  • Используйте общее пространство имен верхнего уровня, чтобы можно было легко идентифицировать все, что является частью вашей инфраструктуры.Возможно, вам это не «нужно», но это просто кажется глупым.
  • Используйте описательные имена.Такие вещи, как Basti.SpecialFramework.Interfaces.DataAccess.Customer, имели бы для меня большой смысл.
  • Структурирование пространства имен вокруг структуры / архитектуры вашей системы дает много смысла.
  • НаличиеХорошо структурированное дерево пространства имен поможет интерпретировать ключевые работы / термины в одном и том же месте, например: Basti.SpecialFramework.Interfaces.DataAccess.Customer против Basti.SpecialFramework.BaseImplementations.DataAccess.Customer
  • Рассматривайте это немного как разработку информационной архитектуры или тестирование юзабилити: придумайтенабросайте набор имен и посмотрите, смогут ли ваши друзья это выяснить.Эквивалент упражнения Сортировка карт - структурируете ли вы его: [Layer]. [Interface / BaseImplementation] или [Interface / BaseImplementation]. [Layer]?(Я не уверен, как именно вы будете выполнять упражнение по сортировке карт, но я вижу некоторые сильные параллели).
  • Описательные имена, как правило, длинные, это идет вразрез с вашей последней точкой;Я согласен, что длинные имена не могут быть «легкими» и «удобными», но если они четко передают то, что мне нужно знать, я согласен с этим.

Кстати: я уверен, что соглашения об именахсуществуют для библиотек DLL и сборок - я просто не знаю их с ног на голову.Я думаю, я мог бы Google / Bing их, но я думаю, что вы уже сделали это.

...