We are a small software company using .NET technologies. We have a home-brew framework which at first seemed to work well for some of our projects but now we see some problems.
The presentation layer is ASP.NET MVC application. The service layer is a single WCF XML service which we are using with multiple ASP.NET MVC front-ends for intranet and internet clients. To make infrastructure tasks as transparent and automatic as possible, we implemented WCF service somewhat REST-like with Get,GetList,New,Update,Delete methods which operate on DTO (data transfer objects pattern) entities. Each WCF method call is processed through custom WCF behaviors to log each request and also to control authentication and authorization. In our event log we have records which lead to reports like this one:
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.
Authorization also can be controlled easy with checkboxes like Give user John Doe permission to execute operation Get/GetList/New/Update/Delete on entity Foobar.
Our business logic developers create entities, NHibernate mappings (now we think about migrating to something more lightweight like Dapper but that's another story) and then put business logic in our business layer - methods marked with special attributes so our WCF service knows where to dispatch requests for each entity. Essentially, we have anemic domain model with procedural business logic. I know that it's not good approach but it seems easier for novice developers and we have many of them in our team.
Our DTOs are some kind of operation descriptors which do not match single business entities. For example, Update (Foobar) operation might perform two business operations on entities Foo and Bar. Now, what the client sees in the event log is that user John Doe executed Update operation on entity Foobar. The client is confused: "Hey, what is that entity Foobar? I know, we have Foo and we have Bar, but what does it mean when someone executes an Update request on Foobar?" As you see, the problem is that for the client our DTOs do not make much sense - the client knows only about his business objects and he does not care what DTOs we use. But from the other hand, the client also will not be satisfied to see separate operations on Foo and Bar without any connection to the upper level operation performed by users.
The same problem happens also with authorization control - the client is able to enable/disable various REST-like operations on our DTOs but these checkboxes do not make much sense from business logic perspective. This means that if user has rights to execute Update (Foobar) he automatically has rights to do other stuff (what ever is programmed in the Update (Foobar) business method) with entities Foo and Bar. But the client might want to control operations on Foo and Bar separately, and our framework does not support that.
In summary, the problem is that currently we have a single point for logging and auth checks - its our WCF service which mostly works with DTOs which are not directly mapped to business entities familiar to our clients.
One idea to fix the log&auth issues is to implement something like Active Records pattern where each operation automatically adds itself to the event log and checks authorization rules. This would allow us to perform logging and authorization at the business entity level which would make sense for our clients. Is it the best solution? Do we have other options to improve our logging and auth so they make more sense for our clients and still keep our boilerplate code to minimum?
