Улучшение инфраструктуры n-уровневой системы
Мы небольшая софтверная компания, использующая технологии.NET. У нас есть система домашнего приготовления, которая сначала казалась хорошей для некоторых наших проектов, но теперь мы видим некоторые проблемы.
Уровень представления - это приложение ASP.NET MVC. Уровень обслуживания - это одна служба XML WCF, которую мы используем с несколькими интерфейсами 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. Теперь клиент видит в журнале событий, что пользователь Джон Доу выполнил операцию обновления на сущности Foobar. Клиент в замешательстве: "Эй, что это за сущность Foobar? Я знаю, у нас есть Foo и у нас есть Bar, но что это значит, когда кто-то выполняет запрос на обновление на Foobar?" Как видите, проблема в том, что для клиента наши DTO не имеют особого смысла - клиент знает только о своих бизнес-объектах, и ему все равно, какие DTO мы используем. Но с другой стороны, клиент также не будет удовлетворен, увидев отдельные операции на Foo и Bar без какой-либо связи с операцией верхнего уровня, выполняемой пользователями.
Та же проблема возникает и с контролем авторизации - клиент может включать / отключать различные REST-подобные операции в наших DTO, но эти флажки не имеют большого смысла с точки зрения бизнес-логики. Это означает, что если у пользователя есть права на выполнение Update (Foobar) он автоматически имеет право делать другие вещи (что когда-либо запрограммировано в Update (Foobar) бизнес-метод) с юридическими лицами Foo и Bar. Но клиент может захотеть управлять операциями на Foo и Bar по отдельности, и наша среда не поддерживает это.
Таким образом, проблема в том, что в настоящее время у нас есть единый пункт для регистрации и проверки подлинности - это наша служба WCF, которая в основном работает с DTO, которые напрямую не сопоставляются с бизнес-объектами, знакомыми нашим клиентам.
Одна из идей, чтобы исправить проблемы с журналом и аутентификацией, - реализовать что-то вроде шаблона Active Records, в котором каждая операция автоматически добавляется в журнал событий и проверяет правила авторизации. Это позволило бы нам осуществлять регистрацию и авторизацию на уровне бизнес-объекта, что имело бы смысл для наших клиентов. Это лучшее решение? Есть ли у нас другие варианты для улучшения нашего ведения журнала и аутентификации, чтобы они имели больше смысла для наших клиентов и при этом сводили наш стандартный код к минимуму?
1 ответ
Одним из ответов на ваши вопросы может быть шаблон разделения ответственности по командным запросам (CQRS).