Рекомендации по подписке на события

Question

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

У нас есть функциональность для аутентификации и авторизации пользователей, которое организовано с помощью HttpModule, который в основном делает следующее (я только включены наиболее значимые части):

public class FooModule : IHttpModule 
    { 
     private IIdentityProvider _identityProvider; 

     public void Init(HttpApplication context) 
     { 
      _identityProvider = TypeFactory.Create<IIdentityProvider>("...type string from configuration..."); 
      identityProvider.Init(context, ...); 

      context.PostAuthenticateRequest += OnAuthenticateRequest; 
      context.PostAuthenticateRequest += OnAuthenticateRequestLogging; 
     } 

     ... 
    } 

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

Затем в инициализации произвольного поставщика идентичности:

public class BarIdentityProvider : IIdentityProvider 
{ 
    public void Init(HttpApplication httpApplication, ...) 
    { 
     var authorizer = new BarAuthorizationProvider(); 
     authorizer.Init(httpApplication, ...); 

     httpApplication.PostAuthenticateRequest += httpApplication_PostAuthenticateRequest; 
     httpApplication.AuthorizeRequest += httpApplication_AuthorizeRequest; 
    } 

    ... 
} 

И в AuthorizationRequestHandler происходит следующее:

public class BarAuthorizationProvider 
{ 
    public void Init(HttpApplication httpApplication, ...) 
    { 
     httpApplication.PostAuthorizeRequest += OnAuthorizeRequest; 
    } 

    ... 
} 

Как вы можете видеть, есть события, которые подписывались в FooModule , BarIdentityProvider и BarAuthorizationProvider, который для меня встречается как спагетти событий. Кроме того, при этом:

var authorizer = new BarAuthorizationProvider(); 
authorizer.Init(httpApplication, ...); 

Я не ожидал, что authorizer подписаться на различные события и работы «волшебно».

Как разработчик программного обеспечения я ожидаю либо:

1. один HttpModule, который подписывается на необходимые мероприятия и запрашивает провайдера идентификации и авторизации поставщика для идентификационной информации и доступа. Управление событиями минимизируется у поставщиков.
2. несколько HttpModules (то есть аутентификация и модуль авторизации), каждый из которых подписывается на необходимые события. Управление событиями минимизируется у поставщиков.

Я верю или нет аргументов против моего ожидания?

Answer 1

Мой первый вопрос: важно ли, чтобы «обработка событий была минимизирована в провайдерах»? То есть что конкретно преимущество в достижении этой цели?

Я также задаюсь вопросом, что означает «событие спагетти». Я имею в виду, что он четко ссылается на вековую концепцию «кода спагетти», но эта концепция относится к коду, где путь исполнения запутан, чаще всего из-за использования неструктурированного управления потоком (то есть goto). Я не вижу, как при обсуждении обработки событий есть что-то похожее на спагетти.

Другими словами, фраза «спагетти событий» просто кажется предвзятой здесь. То есть слово «спагетти» просто бросается, потому что оно уже понимается как уничижительное. Но, не имея явного возражения против реализации, уничижитель кажется неоправданным сам по себе, и слово «спагетти», похоже, не предлагает действительно полезной метафоры, как это происходит в контексте «кода спагетти».

Итак, вернемся к «минимизации обработки событий в провайдерах». Почему это должно быть важно?Вы пишете, что «обработчики событий здесь не подвержены сомнению», но это указывает на то, что обработчики в провайдерах соответствуют. То есть они действительно работают, что имеет отношение к провайдеру (вероятно, только провайдеру). Так как же еще они могут сделать эту работу?

На мой взгляд (тот факт, что я написал это, предполагает, что ваш вопрос может считаться вне темы, будучи «главным образом основанным на мнениях», но я думаю, что есть объективный способ взглянуть на это, даже если это просто мой мнение :)), одним из больших преимуществ модели программирования на основе событий является сокращение связи. Предполагая, что работа должна быть выполнена где-то, альтернативой этим объектам-провайдерам, подписывающимся на эти события, является какой-то другой объект для понимания потребностей объекта-поставщика и удовлетворения этой потребности от имени объекта-поставщика.

Но тогда вы только что загрузили этот другой объект с определенным знанием объекта-поставщика. Это увеличивает сцепление между типами. Что обычно плохо вещь.

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

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