Аудит LINQ и текущий пользователь с веб-приложением - PullRequest
1 голос
/ 26 февраля 2009

Справочная информация:

У меня есть веб-приложение, для которого мне нужно выполнить аудит базы данных для вставки / удаления / обновления (и, возможно, чтения). Я использую LINQ в качестве своего ORM. Используя некоторые идеи, которые я нашел в Интернете, я нашел способ использования атрибутов для украшения моих сущностей, которые имеют связанные таблицы аудита. Сама таблица аудита должна включать те же столбцы с теми же типами, что и исходная таблица, в дополнение к полям для идентификатора и имени текущего пользователя, типа модификации, времени модификации и того, была ли операция успешной или нет. Аудит происходит во время SubmitChanges - мой контекст данных является абстрактным, и я наследую и переопределяю SubmitChanges в моей конкретной реализации. Фактически абстрактный контекст данных происходит от AbstractAuditableDataContext, который расширяет DataContext и добавляет свойство CurrentUser с заполнителями для текущего идентификатора пользователя и имени. По умолчанию это 0 и «system» для случаев, когда нет вошедшего в систему пользователя - скажем, при регистрации или входе в систему, когда некоторые поля пользовательской таблицы могут быть обновлены. Приложение написано на C # с использованием ASP.NET MVC.

Проблема:

Каков наилучший способ заполнить текущее пользовательское свойство моего производного контекста данных? Должен ли я создать служебный класс, который будет вставлен в AuditUtility, который проверяет, был ли установлен CurrentUser, и, если нет, заполняет его. Для тестирования я бы смоделировал это, но в живом приложении оно, вероятно, использовало бы ленивый -загрузка и получить / установить его в сеансе. Или я должен изменить фабрику контекста данных (используется всеми контроллерами) для выполнения этой функции. Я уже использую фиктивную фабрику во время модульного тестирования, так что это не потребует создания новых классов. Или же деривация должна производиться вне фабрики, а текущий пользователь вводится во время создания контекста. Это позволило бы мне проводить аудит «от имени».

Я понимаю, что это несколько субъективно, но я был бы признателен за любые мысли / опыт, которые вы могли бы внести.

Спасибо.

Ответы [ 4 ]

1 голос
/ 26 февраля 2009

Если вы используете аутентификацию Windows или Forms, вы можете проверить HttpContext, ничего не передавая. Если вы не находитесь в веб-контексте, извлеките пользователя из потока. Может быть:

if(HttpContext.Current != null)
{
    //grab the user from the HttpContext
}
else
{
    //grab the user from the Thread
}
1 голос
/ 26 февраля 2009

System.Threading.Thread.CurrentPrincipal должен дать вам ответ, который вы ищете.

0 голосов
/ 25 марта 2009

Я закончил тем, что создал класс CurrentUserUtilityBase, у которого есть метод GetAuditUser, который берет текущий контекст данных и извлекает объект пользователя, который соответствует текущему имени пользователя в HttpContext.User.Identity. Он использует этот объект для извлечения идентификатора и отображаемого имени текущего пользователя, а также для создания и возврата объекта AuditUser, содержащего эти свойства.

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

0 голосов
/ 26 февраля 2009

Каков объем вашего DataContext (приложения, сеанса, запроса, для каждого BusinessObject ..)? Если это меняется, вы можете вообще не захотеть кэшировать текущего пользователя в DataContext (или установить его при создании). Я бы, вероятно, использовал свойство внутри DataContext, которое извлекало текущего пользователя из сеанса (так или иначе) всякий раз, когда это необходимо.

...