The problem that we are going to solve is related to an employee benefit management system. This is a system where the employees of an organization can log in and see the benefits that they are entitled to and utilize the benefits. A very simple example of an employee benefit is leave. Every employee of an organization is entitled to get paid or unpaid leave. Employees have the right to take days off when they need by using their leave entitlement, but there are rules around how many leaves a particular employee is entitled to and how he/she can utilize his/her leave.
There are two main actors or end users of this system. The first is evidently an employee, and the second is an administrator user. An employee can see only his/her benefits. An administrator user on the other hand can see everyone else's benefits and can add/delete benefits. An administrator can be an employee himself/herself.
This is a brief of our problem statement. As you can see, this can be a quite big and complex problem. There is a boatload of benefits that employers offer these days. There are complex rules about who is eligible for which benefits, in what circumstances can the employees utilize the benefits, how exactly does the utilization works, who approves the employee requests for the utilization of a particular benefit, and so on. The aim of this book is to learn NHibernate and not build a sophisticated employee benefit management system, so I am going to use a subset of the requirements of this system that will help us navigate through the chapters of this book with a common understanding of the business problem that we are working with. I am going to be careful to choose only those requirements that let me demonstrate most of the features of NHibernate without having to invest time in trying to understand the problem at hand. With that clear, here are main highlights of the problem subset that we will try to address:
- There are only two actors in this system. One is an employee, and the other is an administrator user.
- An administrator user can be an employee and is entitled to some benefits of his/her own.
- An administrator can add new benefits into the system or can update the existing benefits.
- For auditing and legal reasons, a benefit cannot be deleted from the system.
- Some benefits may have entitlements associated with them. For example, an employee gets 20 paid leaves every year. Our system holds the available entitlements for every employee, but the management of leave happens outside of our system. For example, the organization has a different leave management system where employees can apply for their leave, which are approved by their line managers.
- Since the utilization of the benefits happens outside of this system, it needs to import data from those systems in order to reflect the correct benefits and their entitlements. This import can be a batch job run every night.
- This system supports the following benefits:
- Leave: Paid, sick, and unpaid leave
- Season ticket loan: Employer pays you for an annual public transport pass to commute to work and you repay the employer in monthly payments
- Skill enhancement allowance (or training allowance): All employees are eligible to go for trainings paid for by the employer
There are additional system requirements that I am going to look into later in the book. However, it is worthwhile to mention them now. These requirements give us an opportunity to explore some interesting features of built into NHibernate. Without NHibernate, these features would require a significant time investment to get implemented correctly.
- It is possible that two administrator users could update the same record at the same time. The results of such operations are unpredictable, and usually only the first update is on the correct version of data; the rest are all on a stale copy of the data. Our data access layer needs to be able to detect when an update is happening on a stale copy of data and abandon it.
- Systems like these hold important information. Further, when there are multiple users acting on the data, chances are things would go wrong for one reason or the other. Organizations usually do not like to be in a situation where their employees get agitated because the system is not reflecting the correct information about the benefits that they are entitled to. If such a thing happens, organizations need to know how the data came to be in that state. This not only helps with understanding what went wrong but also gives an opportunity to fix any system defects quickly. For this reason, we would like to maintain a data audit for every change made to any data via this system.
You do not have to worry about the last three requirements just now. We will visit this in the later chapters of this book. I have presented these here for the sake of completeness of the problem.
If you are wondering whether this is a web-based system or a desktop application, I would suggest that you do not bother yourself. Our aim is only to build a suitable data access layer for this system that can be used by any kind of application. With this clear, let's proceed to our development setup to know more about the tools that I will be using to implement this solution.