Подтвердить что ты не робот

Как вы управляете пространствами имен ваших методов расширения?

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

Или вы используете какой-то другой метод, например, пространство приложений или библиотеки?

Я спрашиваю, потому что мне нужно расширить System.Security.Principal.IIdentity, и, по-видимому, использование метода расширения в пространстве имен System.Security.Principal имеет смысл, но я никогда не видел, чтобы это делалось именно так.

4b9b3361

ОТВЕТЫ

Ответ 1

Я бы рекомендовал разместить все ваши методы расширения в одном пространстве имен (кстати, это также то, что Microsoft сделала с Linq, поставив их в один класс "Расширения" внутри пространства имен System.Linq).

Так как Visual Studio не дает никаких указаний о том, как найти метод расширения, который вы хотите использовать, это уменьшает путаницу, только имея в виду одно пространство имен.

Ответ 2

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

  • Если вы пишете расширение для Uri, поместите расширение в System.
  • Если это расширение для DataSet, поместите его в System.Data.

Кроме того, Microsoft говорит о методах расширения:

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

Дополнительные сведения о методах расширения см. в странице MSDN о методах расширения.

Ответ 3

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

В этой категории, например:
.IsNullOrEmpty(this string value) и .HasValue(this string value)

Однако, если они очень специфичны и редко используются, я помещаю их в пространство имен BaseNamepace.Extensions, поэтому их нужно вручную импортировать и не показывать в intellisense всевозможные помехи.

Ответ 4

Я поддержал ответ от user276695, который казался самым простым решением. Однако я нашел еще лучшее решение: никакого пространства имен вообще. Вы можете поместить статический класс с методами расширения в самый корень файла, не обертывая вокруг него никакое объявление пространства имен. Тогда методы расширения будут доступны без необходимости импорта/использования любого пространства имен. †

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

† Вы также можете сохранить один уровень отступов.:-) И даже с тремя гигантскими мониторами я всегда ищу способы сохранить экранную недвижимость.

Ответ 5

Моя практика заключается в том, чтобы поместить расширения в пространство имен, которое отличается от еще четкого определения пространства имен источников, которое я расширяю.

Как правило, я создаю пространство имен путем префикса части "название компании" пути пространства имен перед пространством имен, которое я расширяю, а затем суффикс его с ".Extensions"

Например, если я расширяю (без уважительной причины) ::System.Text.StringBuilder, потому что он запечатан, тогда я поместил свои расширения в пространство имен ::CodeCharm.System.Text.Extensions.

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

Ответ 6

Если вы помещаете их в более высокое пространство имен, чем ваше текущее, они будут отображаться автоматически.

Итак, если у вас есть пространства имен для таких проектов, как:

AdventureWorksInc.Web
AdventureWorksInc.Logic
AdventureWorksInc.DataAccess

Затем объявите расширение напрямую:

namespace AdventureWorksInc
{
   public static class HtmlHelpers
   {
       public static string AutoCloseHtmlTags(this string html)
       {
           //...
       }

   }
}

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

Однако вышеуказанное расширение демонстрирует возможный недостаток. Из-за того, что он работает со строками, он теперь будет отображаться как метод расширения для всех строк, включая те, которые на самом деле не являются HTML. На самом деле это не проблема с областью определения пространства имен, а просто неправильное использование метода расширения. Это должно быть постоянным статиком, для которого требуется стандартный параметр, поэтому вызов явственен.

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