Saturday, March 30, 2019

Generic Insert/Update/Delete Permission Checking Using Reflection

Summary:

A good number of developers spend their time in working with LOB (business) applications wether Desktop or Web. Most of the business applications revolve around CRUD operations on several entities and each CRUD method usually requires Permission Checking routine. In this post we shall see how we can utilize the Reflection to create a generic Permission Checking method in order to minimize the code writing.

Download: Visual Studio C# Project GenericPermission_Reflection.zip

Level: Expert

Knowledge Required:
  • Reflection
  • Application Architecture
  • Some ORM e.g. Entity Framework
Description

For this post, I have created a sample business application which just keeps track of customer sales orders. To make project simple, I haven’t implemented any Data Access code. Usually in business applications we have 3 layers, UI / Presentation Layer, Data Access Layer and Business Layer. Since this post only focuses on business layer functionality therefore, we’ll not have any UI or Data Access Layer implementation.

In this application I have created 4 entities

As you can notice that other than 4 entity classes, we have RecordState enum and EntityBase class. All the 4 POCO entity classes are inhertied from the EntityBase class.

As shown in above image, the EntityBase class has RecordState property which tells the current state of the object that we are about to manipulate. I am assuming that you are already familiar with different ORMs like Entity Framework, which uses similar approach to check what DB operation (insert/update or delete) needs to be performed on the data. A quick recap of this approach is that, each entity is loaded from database with RecordState = Unchanged, then it is passed to user interface, later user makes changes on the user interface which changes the RecordState = Updated, then this object with RecordState = Updated is sent back to the Business Layer and finally business layer performs DB Update using Data Access Layer. Similarly, RecordState property can be used to create a new record or to delete a record by setting appropriate value in RecordState property.

And we also have defined the RecordState enum

Now assume that we are about to create methods in our business layer to manipulate Item entity.

First method that we defined is Item_Get method. It’s pretty straight forward and just loads 1 record from database and return it to the caller which can be a presentation layer.

Next method we will define is Item_Save method.

As you can see, we haven’t implemented the method much and only defined the basic structure of this method. The Item class that we are using in this method has already been inherited from EntityBase class so it will automatically have the RecordState property.

We are about to implement the permission checking in this method, but for this we have created a separate class for permissions.

It’s a good approach to keep the constants aside. Although, we could define these constants within our business layer, but it’s better to keep them like this in separate class. This will also help us in implementing the generic permission checking method.

To check whether the currently logged-in user has certain permission or not I’ve created a separate method in our business layer as well.

Again, here we are not implementing actual permission checking code because it’s beyond the scope of this article.

Now we are good to go to implement the permission checking in our Item_Save method

As you can see above, we are checking the current RecordState property of Item and then we are validating if the current user has respective permission.

Now this is for 1 entity only i.e. Item entity, imagine if you have 50 entities and you have to write 50 Save methods. It would be easier if there is some generic method which we could use to avoid writing the same repeated code again and again. This is what we are going to achieve using Reflection.

First, we’ll create an Attribute class to create a link between different permissions constants and respective entity.

Next, we’ll add this Attribute class with each permission

We are actually linking the permission with the entity and also, we are telling for which RecordState this permission should be used.

Finally, we can define our generic permission testing method

In above method we are using Reflection to extract all the permissions where our special attribute is set, then we are trying to extract the exact permission which is matching with the given entity’s Type and RecordState, once we found the correct permission constant we pass it in our HasPermission method, if it returns false (does not have permission). Then we through exception as per the RecordState.

After this, we can implement this generic save permission checking method in our Item_Save method