如何在业务层实现审计
本文关键字:实现 审计 业务 | 更新日期: 2023-09-27 18:00:59
我正在尝试为一个用户可以登录、更改密码和电子邮件等的系统实现基本审计。
我想审计的函数都在业务层中,我想创建一个审计对象,存储调用函数的日期时间,包括结果。
我最近参加了一个会议,其中一个会议是关于精心制作的网络应用程序,我正在努力实现其中的一些想法。基本上,我使用Enum来返回函数的结果,并使用switch语句来更新该层中的UI。这些函数使用早期返回,不会留下任何时间来创建、设置和保存审核。
我的问题是,其他人在审计业务职能时会采取什么方法,如果你有像我这样的职能,你会采取什么方式(如果你说放弃它,我会听,但我会很暴躁(。
代码看起来有点像这样:
function Login(string username, string password)
{
User user = repo.getUser(username, password);
if (user.failLogic1) { return failLogic1Enum; }
if (user.failLogic2) { return failLogic2Enum; }
if (user.failLogic3) { return failLogic3Enum; }
if (user.failLogic4) { return failLogic4Enum; }
user.AddAudit(new (Audit(AuditTypeEnum LoginSuccess));
user.Save();
return successEnum;
}
我可以扩展if语句,在每个语句中创建一个新的审计,但随后函数开始变得混乱。我可以在switch语句的UI层中进行审计,但这似乎是错误的。
用finally将其全部粘贴在try-catch中,并使用finally创建Audit对象并在其中设置其信息,从而解决早期返回问题,这真的很糟糕吗?我的印象是,a最终是为了清理而不是审计。
我的名字叫大卫,我只是想成为一个更好的代码。谢谢
我不能说我用过它,但这似乎是面向方面编程的候选者。基本上,您可以在每个方法调用中以自动化的方式为日志记录/审计等内容注入代码。
另外,制作try/catch/finally块并不理想,但我会计算一下成本效益,看看它是否值得。如果你能合理地以低廉的成本重构代码,这样你就不必使用它了,那就这样做吧。如果费用太高,我愿意试一试。我认为很多人都会陷入"最佳解决方案",但时间/金钱总是有限制的,所以要做"有意义的"。
枚举的问题是它不是真正可扩展的。如果以后添加新组件,则Audit框架将无法处理新事件。
在我们使用EF的最新系统中,我们在实体名称空间中为审计事件创建了一个基本的POCO:
public class AuditEvent : EntityBase
{
public string Event { get; set; }
public virtual AppUser AppUser { get; set; }
public virtual AppUser AdminUser { get; set; }
public string Message{get;set;}
private DateTime _timestamp;
public DateTime Timestamp
{
get { return _timestamp == DateTime.MinValue ? DateTime.UtcNow : _timestamp; }
set { _timestamp = value; }
}
public virtual Company Company { get; set; }
// etc.
}
在我们的任务层中,我们实现了一个抽象的基础AuditEventTask:
internal abstract class AuditEventTask<TEntity>
{
internal readonly AuditEvent AuditEvent;
internal AuditEventTask()
{
AuditEvent = InitializeAuditEvent();
}
internal void Add(UnitOfWork unitOfWork)
{
if (unitOfWork == null)
{
throw new ArgumentNullException(Resources.UnitOfWorkRequired_Message);
}
new AuditEventRepository(unitOfWork).Add(AuditEvent);
}
private AuditEvent InitializeAuditEvent()
{
return new AuditEvent {Event = SetEvent(), Timestamp = DateTime.UtcNow};
}
internal abstract void Log(UnitOfWork unitOfWork, TEntity entity, string appUserName, string adminUserName);
protected abstract string SetEvent();
}
必须实现Log来记录与事件相关联的数据,并且实现SetEvent来强制派生任务隐式设置其事件的类型:
internal class EmailAuditEventTask : AuditEventTask<Email>
{
internal override void Log(UnitOfWork unitOfWork, Email email, string appUserName, string adminUserName)
{
AppUser appUser = new AppUserRepository(unitOfWork).Find(au => au.Email.Equals(appUserName, StringComparison.OrdinalIgnoreCase));
AuditEvent.AppUser = appUser;
AuditEvent.Company = appUser.Company;
AuditEvent.Message = email.EmailType;
Add(unitOfWork);
}
protected override string SetEvent()
{
return AuditEvent.SendEmail;
}
}
这里的问题是内部的基本任务——基本任务可以是公共的,这样以后添加到task命名空间中就可以使用它——但总的来说,我认为这给了你这个想法。
当涉及到实现时,我们的其他任务决定何时应该进行日志记录,因此在您的情况下:
AuditEventTask task;
if (user.failLogic1) { task = new FailLogin1AuditEventTask(fail 1 params); }
if (user.failLogic2) { task = new FailLogin2AuditEventTask(fail 2 params); }
if (user.failLogic3) { task = new FailLogin3AuditEventTask(etc); }
if (user.failLogic4) { task = new FailLogin4AuditEventTask(etc); }
task.Log();
user.Save();