ASP.NET MVC предлагает нам много частей в коде, в которых мы можем изменить предопределенное поведение функций, которые предоставляются нам по умолчанию при запуске наших проектов. Эти изменяемые части позволяют нам изменять корень, используя одно и то же имя компонентов, поэтому нам не нужно переписывать весь код, но единственное, к чему мы прикасаемся, - это основа, которую мы хотим изменить.
Когда мы говорим о вышеизложенном и видим его с точки зрения контроллеров, это позволяет нам создавать аспекты, то есть модификаторы, которые влияют только на конкретный контроллер без необходимости создавать новую структуру, все в соответствии с хорошими практиками ASP . .NET MVC .
Аспектно-ориентированное программирование
Это приводит нас к новой форме программирования, которая является аспектно-ориентированной, возможно, ее концепция немного сложна для ассимиляции с первого раза, но это означает, что она способна включать изменения и функциональные возможности без изменения нашего кода. Не все языки имеют такую возможность, однако ASP.NET имеет ее, что делает ее использование чем-то родным и без необходимости поиска сторонних библиотек для получения необходимых результатов.
Модифицируемые модели
Это структуры, которые дают нам основу для внесения наших изменений, они являются своего рода контрольными точками, на которые мы можем поместить наш код и сгенерировать наше собственное поведение, отличное от того, что предлагает инфраструктура .
Чего мы добиваемся?
Таким образом, мы можем включать более сложные и законченные модули, что делает наше приложение более надежным и приближенным к нашим потребностям, с этим мы также можем создавать нашу структуру, которая может масштабироваться в будущем без особых усилий на уровне базового кода.
Чтобы использовать эти модели, у нас есть две возможные реализации: модель на основе провайдера, а другая реализация - это шаблон локатора службы, у обеих есть способ установить себя в наших приложениях, с целью использования различных методологий модификации приложений. стандартных компонентов ASP.NET MVC .
Модель на основе поставщика
В этом подходе мы будем работать путем прямой замены внутренних компонентов ASP.NET MVC, что делает нас полностью ответственными за то, что происходит в приложении, и если есть проблема с производительностью или сбоем, мы должны перейти непосредственно к обзору. наш код
Очень популярный случай, объясняющий эту модель, - это когда нам нужно сделать временное хранилище данных, это позволяет нам сохранять данные, чтобы они могли выжить, делая повторный адрес страницы, которая создает их по запросу браузера.
На следующем рисунке мы увидим код, в котором установлен альтернативный модуль сохранения данных с использованием файлов cookie, а затем модель распределенного кэша, последний дает нам ответственность за то, как сохранить данные и поддерживать их согласованность.
Если мы проанализируем его в холодном состоянии, это будет своего рода наследование, однако характеристики структуры делают его более продвинутым.
Шаблон локатора службы
Эта модель отличается от предыдущей, поскольку она имеет центральный класс, доступный объектам классов, которые реализуют ее как интерфейс, а также используют методы реализации «контракта» .
Как это работает
Для использования в наших компонентах клиентский компонент просто запросит у нашего локатора услуг любой элемент, который соответствует желаемому поведению, на который последний после поиска своего контента ответит с желаемой функциональностью. Обычно эта модель применяется, когда нашим классам необходимо использовать внешние компоненты, выполняя своего рода проверку зависимостей проекта.
В следующем коде, представленном на следующем изображении, мы видим ясный пример того, что мы объяснили:
Наконец, обычным способом мы можем применить возвращенные сервисы и использовать их как часть нашего прикладного компонента. Это значительно облегчает процесс разработки, и у нас могут быть наши собственные реализации.
Добавление аспектов в наши контроллеры$config[ads_text5] not found
Поскольку мы видели разные способы настройки нашего приложения с помощью изменений в его компонентах, чтобы добавить аспекты к нашим контроллерам, мы можем сделать это с помощью атрибутов, которые мы можем поместить в их классы, это достигается путем определения методов перед определение их. В других языках это также можно рассматривать как декораторы, которые являются методами, которые выполняются или которые изменяют класс, в котором они определены.
Фильтры действий
Это очень интересные аспекты, так как в соответствии с определением, которое мы им даем, они позволяют нам выполнять код до или после выполнения действий нашего контроллера, например, мы можем поместить аспект, который выполняет такую функцию, как создание системного журнала непосредственно перед что значение вставляется в базу данных, а затем еще один аспект, заключающийся в том, что после завершения процесса вызывается метод, который обновляет уведомления администратора .
В следующем коде мы увидим, как мы можем определить Фильтр Действий в контроллере, в этом случае мы определяем, что перед выполнением мы фиксируем время и дату момента, затем, когда он завершится, мы посчитаем время, которое потребовалось для всего этого процесса.
Для этого мы сначала используем методы интерфейса:
открытый интерфейс IActionFilter {void OnActionExecuting (ActionExecutingContext filterContext); void OnActionExecuted (ActionExecutedContext filterContext);} Где OnActionExecuting - выполнить действие перед желаемым контроллером, а OnActionExecuted - последующее действие. Давайте посмотрим на изображение полного кода: 
Типы результатов действий
В большинстве взаимодействий, которые мы имеем с нашими контроллерами, мы получаем ответ « Результат действия» в конце всего процесса. Этот ответ является одним из аспектов наших контроллеров, которые мы также можем изменить для работы с нашим приложением по-своему.
Ответ Действие Результат$config[ads_text6] not found
Ответ « Результат действия» обычно позволяет нам передавать данные непосредственно в браузер, тем самым сохраняя этап обработки, конечно, не все, что мы делаем, потребует, чтобы это происходило таким образом, однако это то, что мы можем принять во внимание.
С помощью этого мы можем установить коды ответов, статус, тип контента (который широко используется для асинхронных запросов) и т. Д.
В следующем примере мы увидим, как мы можем сгенерировать пользовательский код состояния, чтобы, когда браузер получил его, он мог выполнить действие. Для этого мы сначала определим класс, который устанавливает ответ на действие, с кодом и его соответствующим описанием. Затем в методе мы можем вызвать результат действия и передать код, который мы хотим получить браузером, чтобы у нас был полный цикл. Давайте посмотрим на соответствующий код изображения:
Однако вся эта гибкость достигается за определенную цену, и, поскольку настройки, не протестированные таким сообществом, как Microsoft, мы можем обнаружить проблемы с производительностью или сбои в работе, в этих случаях идеальным всегда будет сначала взглянуть на наш собственный код.
На этом мы завершили этот урок, так как мы видим, что ASP.NET позволяет нам вносить изменения, настраивая многие области и многие из его собственных компонентов, что делает достигнутую гибкость очень высокой. Можно также упомянуть, что аспектно-ориентированное программирование набирает силу в течение нескольких лет, поэтому освоение всех этих тем становится обязательным, если мы хотим улучшить наше резюме и достичь более иерархической и платежной системы - экосистемы. ASP.NET MVC является фаворитом этой парадигмы, и Microsoft с ее новыми выпусками, несомненно, сделает платформу более принятой во внимание.$config[ads_text6] not found
СТАТЬИ