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

Question

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

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

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

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

Answer 1

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

Answer 2

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

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

Answer 3

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

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

, а затем на (5,6) о методах расширения:

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

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

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

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