ведение журнала mvc: [LogRequest] против OnActionExecuting - PullRequest
Новая
       32

ведение журнала mvc: [LogRequest] против OnActionExecuting

3 голосов
/ 29 сентября 2011

Я - .net / c # noob (давний разработчик сервлетов / Java)

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

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

, как я вижу, я могу добавить атрибут [LogRequest] к контроллеру (в моем случае, базовый контроллер) и затем реализовать 

public class LogsRequestsAttribute : ActionFilterAttribute, IActionFilter
{
    void IActionFilter.OnActionExecuting(ActionExecutingContext filterContext)
    { ... }
}

класс для обработки атрибута logrequest.

или

Я мог бы просто переопределить базовый контроллер согласно: 

public class BaseController : Controller
{
    protected override void OnActionExecuting(ActionExecutingContext filterContext)
    {
       // perform some action here
    }
}

и наследовать все мои контроллеры от BaseController.

с точки зрения производительности, что было бы быстрее?

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

1 Ответ

4 голосов
/ 29 сентября 2011

Если вы используете MVC3, я бы рекомендовал добавить ваш фильтр действий в коллекцию глобальных фильтров, а не требовать базового контроллера.При запуске приложения в вашем классе Global.asax ("MvcApplication") вам потребуется строка типа: 

GlobalFilters.Filters.Add(new LogRequestsAttribute());

, которая будет запускать ее для всех действий контроллера.

ИзС точки зрения производительности, я не думаю, что вы увидите большую разницу между атрибутом или механизмом базового контроллера.Я не пробовал, но поскольку часть фильтра действий в конвейере MVC будет работать независимо от того, есть ли у вас базовый контроллер, реальным соображением здесь будет гибкость, а не производительность.Более гибкий дизайн заключается в том, чтобы изолировать протоколирование от контроллера.

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

...