Рекомендации: С# Расширение пространства имен и продвижение методов расширения

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

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

MyCompany.Web.Utils

и внутри я имею классы метода расширения. Это хорошо для меня с недостатком, что расширители не сразу видны нашим разработчикам программного обеспечения. Рассмотрим случай, когда у меня есть класс StringExtender, который предоставляет довольно удобный метод расширения "В" , который расширяет объект String. Имея метод расширения с указанным выше пространством имен, наши программисты не будут видеть метод расширения, если они явно не включают его пространство имен. Вместо этого, если бы я поместил метод расширения в пространство имен System, все сразу увидели бы его, но я прочитал, что это плохая практика.

Итак, мой вопрос заключается в том, как вы продвигаете свои методы расширения s.t. они используются вашими разработчиками.

Ответ 1

Мы помещаем их все в свое собственное пространство имен Company.Common.Extensions. Таким образом, если у вас есть какой-либо из наших методов расширения, у вас есть все они. Кроме того, по крайней мере, в моем магазине нам не нужно беспокоиться о том, что наши разработчики не знают о методах расширения. У меня есть противоположное беспокойство, перегрузка метода расширения!:)

Ответ 2

Проблема здесь не в названии пространства имен, отсутствии документации и образовании ваших разработчиков.

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

Ответ 3

Это не проблема пространства имен, это проблема связи.

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

Размещение чего-либо в пространстве имен System - это рецепт катастрофы и путаницы позже. Единственный раз, когда вы когда-либо хотели это сделать, - это функциональность "back port" в старых фреймворках, и тогда вы, вероятно, не должны делать это самостоятельно, но для этого нужно использовать что-то вроде LinqBridge.

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

Сохранение пространства имен название компании является разумным в целом, чтобы избежать путаницы.

Ответ 4

@Juri- Если вы думаете об этом, это та же проблема, что и разработчики, зная, что класс X существует в платформе .NET. Коммуникация является ключом к тому, что все члены команды используют правильные классы, будь то методы расширения или какой-то другой помощник.

Как заявил JP, я часто вижу методы расширения в какой-то подпапке под названием Extensions. Надеюсь, когда вы укажете, что используете my.company.web.utils, пространство имен на самом деле обложено Паскалем?

Даже если вы положите их в хорошее место, нет 100% гарантии, что другие разработчики будут их использовать.

Ответ 5

Предполагая, что вы используете Visual Studio, одним из способов было бы создать собственный шаблон класса (или изменить его по умолчанию), чтобы всякий раз, когда разработчик создает новый файл класса, у него автоматически есть оператор using с вашими пространствами имен. См. C ustomize Шаблоны Visual Studio 2005 для производительности кодирования.

Ответ 6

Да, я думаю, что методы расширения в собственной компании namespce - это лучшие практики. поместить его в пространство имен System - это ленивая операция

Ответ 7

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

Ответ 8

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

Например:

ExtensionMethods-String.cs

ExtensionMethods-DataObject.cs

ExtensionMethods-Debug.cs

... и т.д. все имеют частичные классы...

Ответ 9

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

Ответ 10

Мне нравится, как ReSharper решает эту проблему.

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

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

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

AddMvc
AddEntityFrameworkSqlServer (Microsoft.Extensions.DependencyInjection)