Почему некоторые методы HtmlHelper реализованы как методы расширения

Question

В настоящее время я создаю несколько пользовательских вспомогательных классов, аналогичных стандарту ASP.NET MVC HtmlHelper. Когда я посмотрел на реализацию HtmlHelper, я заметил, что большинство / все методы генерации HTML (такие как ActionLink(), BeginForm(), TextBox() и т. Д.) Не реализованы непосредственно внутри класса HtmlHelper, но как методы расширения в отдельных классах (например, в class LinkExtensions).

Есть ли какое-то преимущество при реализации таких методов, как методы расширения вместо обычных методов, кроме более приятной организации исходного кода?

При создании своих собственных вспомогательных классов я должен также следовать этому шаблону?

Обновление : когда я писал, что хочу создать свой собственный вспомогательный класс, тогда я действительно хотел расширить существующий класс HtmlHelper. Вместо этого я создал собственный базовый класс для своих представлений (производный от ViewPage) и хочу добавить туда дополнительный вспомогательный класс, аналогичный вспомогательным классам Html и Url в ViewPage.

Answer 1

I предположим, это может быть из-за того, что Руководство по проектированию структуры упоминает (4.1):

Избегайте использования типов, разработанных для сложных сценариев, в одном пространстве имен с типами, предназначенными для общих задач программирования.

и позже (5.6) о методах расширения:

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

Сам Фил Хаак упоминает на той же странице, что они помещают «более продвинутую» функциональность в отдельное пространство имен, чтобы не «загрязнять» API расширенного типа.

Я согласен, что более полезные методы (ActionLink и т. Д.) Менее обнаружимы, но все они реализованы с использованием базового API HtmlHelper (GenerateLink и т. Д.), Который является частью основного Пространство имен.

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

Answer 2

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

Answer 3

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

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