Мы небольшая компания-разработчик программного обеспечения, использующая технологии .NET. У нас есть самодельный фреймворк, который поначалу хорошо работал для некоторых наших проектов, но теперь мы видим некоторые проблемы.
Уровень представления представляет собой приложение ASP.NET MVC. Уровень службы — это единая служба WCF XML, которую мы используем с несколькими интерфейсами ASP.NET MVC для клиентов интрасети и Интернета. Чтобы сделать задачи инфраструктуры максимально прозрачными и автоматическими, мы реализовали службу WCF, несколько похожую на REST, с методами Get, GetList, New, Update, Delete, которые работают с объектами DTO (шаблон объектов передачи данных). Каждый вызов метода WCF обрабатывается с помощью настраиваемого поведения WCF для регистрации каждого запроса, а также для управления проверкой подлинности и авторизацией. В нашем журнале событий у нас есть записи, которые приводят к таким отчетам:
During activity with id {guid-here} User John Doe from IP executed Update operation on entity Foobar. Operation result was Success/DataValidationFailure/AuthorizationFailure/UnknownFailure etc.
Авторизацией также можно легко управлять с помощью флажков типа Give user John Doe permission to execute operation Get/GetList/New/Update/Delete on entity Foobar.
Наши разработчики бизнес-логики создают сущности, сопоставления NHibernate (теперь мы думаем о переходе на что-то более легкое, например Dapper, но это уже другая история), а затем помещают бизнес-логику на наш бизнес-уровень — методы, помеченные специальными атрибутами, чтобы наша служба WCF знала, куда отправлять запросы. для каждой сущности. По сути, у нас есть анемичная доменная модель с процедурной бизнес-логикой. Я знаю, что это нехороший подход, но начинающим разработчикам, а таких в нашей команде много, он кажется более простым.
Наши DTO — это своего рода дескрипторы операций, которые не соответствуют отдельным бизнес-сущностям. Например, операция Update (Foobar) может выполнять две бизнес-операции с сущностями Foo и Bar. Теперь то, что клиент видит в журнале событий, это то, что пользователь John Doe выполнил операцию обновления на объекте Foobar. Клиент в замешательстве: «Эй, что это за объект Foobar? Я знаю, у нас есть Foo и у нас есть Bar, но что это значит, когда кто-то выполняет запрос на обновление на Foobar?» Как видите, проблема в том, что для клиента наши DTO не имеют особого смысла — клиент знает только о своих бизнес-объектах и ему все равно, какие DTO мы используем. Но, с другой стороны, клиент также не будет удовлетворен, увидев отдельные операции над Foo и Bar без какой-либо связи с операциями верхнего уровня, выполняемыми пользователями.
Та же проблема возникает и с контролем авторизации — клиент может включать/отключать различные REST-подобные операции в наших DTO, но эти флажки не имеют большого смысла с точки зрения бизнес-логики. Это означает, что если у пользователя есть права на выполнение Update (Foobar), он автоматически получает права делать другие вещи (все, что когда-либо запрограммировано в бизнес-методе Update (Foobar)) с сущностями Foo и Bar. Но клиент может захотеть управлять операциями над Foo и Bar отдельно, а наш фреймворк этого не поддерживает.
Таким образом, проблема заключается в том, что в настоящее время у нас есть единая точка для ведения журнала и проверки подлинности — это наша служба WCF, которая в основном работает с DTO, которые напрямую не сопоставлены с бизнес-сущностями, знакомыми нашим клиентам.
Одна из идей по устранению проблем с журналом и авторизацией состоит в том, чтобы реализовать что-то вроде шаблона Active Records, где каждая операция автоматически добавляет себя в журнал событий и проверяет правила авторизации. Это позволило бы нам выполнять регистрацию и авторизацию на уровне бизнес-объектов, что было бы целесообразно для наших клиентов. Это лучшее решение? Есть ли у нас другие варианты улучшения нашего ведения журналов и аутентификации, чтобы они были более понятными для наших клиентов и при этом сводили наш шаблонный код к минимуму?
