我们是一家使用.NET技术的小型软件公司。我们有一个家庭酿造框架，起初似乎对我们的一些项目很有效，但现在我们看到了一些问题。
表示层是ASP.NET MVC应用程序。服务层是单个WCF XML服务，我们将其与多个ASP.NET MVC前端一起用于Intranet和Internet客户端。为了使基础架构任务尽可能透明和自动化，我们使用Get，GetList，New，Update，Delete方法实现了WCF服务，这些服务在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上执行了Update操作。客户感到困惑：“嘿，那个实体Foobar是什么？我知道，我们有Foo而且我们有Bar，但是当有人在Foobar上执行更新请求时它意味着什么？”如您所见，问题是对于客户端我们的DTO没有多大意义 - 客户端只知道他的业务对象，他不关心我们使用什么DTO。但另一方面，客户也不满足于在没有任何与用户执行的上层操作的连接的情况下在Foo和Bar上看到单独的操作。
同样的问题也发生在授权控制上 - 客户端能够在我们的DTO上启用/禁用各种类似REST的操作，但从业务逻辑的角度来看，这些复选框没有多大意义。这意味着如果用户有权执行Update (Foobar)，他自动有权使用实体Foo和Bar执行其他内容（在Update (Foobar)业务方法中编程）。但是客户端可能想要分别控制Foo和Bar上的操作，而我们的框架不支持它。
总之，问题在于目前我们只有一个点用于日志记录和身份验证 - 它是我们的WCF服务，它主要与DTO一起使用，而DTO不直接映射到我们客户熟悉的业务实体。
修复日志和授权问题的一个想法是实现Active Record模式，其中每个操作自动将自身添加到事件日志并检查授权规则。这将允许我们在业务实体级别执行对我们的客户有意义的日志记录和授权。这是最好的解决方案吗？我们是否有其他选择来改进我们的日志记录和身份验证，以便它们对我们的客户更有意义，并且仍然保持我们的样板代码最小化？