Ger Hayden Ответов: 3

Рекомендации по проектированию полезного метода, который на самом деле не принадлежит классу

У меня есть несколько контроллеров .NET Core web API, которым потребуется метод заголовка validate.

Он будет делать то же самое на каждом контроллере. Я хотел бы научиться правильно проектировать это.

Что я уже пробовал:

Пока ничего, мой вариант "перейти к" состоит в том, чтобы создать "технический класс" и иметь на нем метод Validate, а затем каждый контроллер создает экземпляр этого технического класса для использования метода Validate. Но это абсолютно ужасный подход. Этот класс ничего не представляет и является просто заполнителем для таких методов, как этот.

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

3 Ответов

Рейтинг:
20

Richard Deeming

Похоже, вам нужно написать какое-то пользовательское "промежуточное по":
ASP.NET основное промежуточное программное обеспечение | Microsoft Docs[^]
Напиши обычай ASP.NET основное промежуточное программное обеспечение | Microsoft Docs[^]

Ger Hayden

Это было бы отличным учебным упражнением.

Рейтинг:
2

phil.o

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

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

Ger Hayden

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

Рейтинг:
13

MadMyche

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

Подобный тип служебного кода известен как Промежуточный слой Промежуточное программное обеспечение состоит из первого и последнего фрагмента кода, который получает запрос, и может выполнять большую часть тех же функций, что и фильтр.
Промежуточное программное обеспечение выполняет многие из тех же ролей, что и HttpModules в более ранних версиях ASP.NET (не ядро).

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

Ключевое различие между Фильтры и Промежуточный слой это то, что промежуточное программное обеспечение применяется ко всем запросам, в то время как фильтры применяются на уровне контроллера или действия.
Это выбор, который вы должны принять - если все ваши запросы должны иметь HeaderValidation, то вы идете с промежуточным программным обеспечением. Если только половина ваших запросов должна пройти через это, то вы идете с фильтром.
"Серая зона" заключается в том, что если только несколько запросов не нуждаются в этом, вы можете написать "специальное исключение" в промежуточное программное обеспечение для конкретных запросов по мере необходимости.

Фильтры внутри ASP.NET ядро | Microsoft Docs[^]
Изучение промежуточного программного обеспечения в качестве фильтров MVC в ASP.NET сердечник 1.1[^]
Промежуточное программное обеспечение против фильтров ASP. NET Core - культист .NET[^]

Ger Hayden

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

MadMyche

Если это будет 100% POST-запросов и 0% остальных, я бы рассматривал это как промежуточное программное обеспечение; это должно быть простое в обслуживании исключение из правила проверки

Ger Hayden

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