Active record.

Problem statement –

It is rare to imagine any software application without records. Records are the most important part of any large software application, we apply business logic on those records and keep them safe and clean.

There are many robust and nice tools to save records - oracle DB, MySql, MS SQL Server, etc. For example I am mentioning a student table below.


Databases are the key layer of any application, but user deal with an interface (or GUI - graphical user interface) developed in some programming language (i.e HTML5, C++, JAVA, C# .NET , etc.) not with database directly, we save our records in database. 



It means you need something which connect to database from your business layer, we have to figure out what? Answer is ORM.


What is ORM?

Some legacy application (which don’t follow all OOPs principles) use DB as just a storage and perform DB operations according to business requirement (from some part of their code base, without applying proper abstraction), and that’s it, then close the connection with DB and reopen connection if they want to update, insert or delete the record. This is not a good practice in most of the cases. Without applying abstraction, your code will become very tough to understand and difficult to maintain. Actually you should apply same abstraction in your code base as it is in database, your object/class should reflect your your table as it is. So the question is how it will work? We will use ORM to apply proper abstraction on records.

Whenever there is a need to work with database, we need an ORM (Object-relational mapping), ORM is a layer between database and your application. It will work seamlessly from UI till last layer (probably DB) and you will be able to insert, update, and read records from DB.

Let us understand it through an example, if we have an student table, which stores students record like - roll number, name, subjects and which standard (class). Through active record we can apply same abstraction in business layer, in your code, and it will always be connected and active every time. If there are any changes in record it will immediately reflect to your database and from database to UI, that is why it is a active record. See the diagram below for more clear understanding -



Lets go in more detail and see how it works. There are fixed number of operations you can perform on database like - insert, update, delete. For all of them we have event handler defined, you can define your own function and hook it to those event handlers.

For any new record, user want to update the student table, so insert event will generate, which will call your insert function, for example -
/*
Return true when insert record successfully otherwise false.
*/

bool insertStudentRecord(string studentName, vecotr<string> subjects,
                            atring standard)
    {
        // roll number will be generated automatically.
        // apply business logic.
    }

You just have to hook your defined function - insertStudentRecord, in your insert event and it will get called at run time whenever user want to insert a new record from GUI.

Same way deleteRecord for delete event -
/*
Return true when delete record successfully otherwise false.
*/
bool deleteRecord(long rollNumber, string standard)
    {
        // apply business logic.
    }


And finally updateRecord for update event -
/*
Return true when update record successfully otherwise false.
*/
bool updateStudentRecord(string studentName, vecotr<string> subjects,
                            string standard)
{
    // apply business logic.
}



Thanks for reading it. To read more on design patterns and basic design principles please see my web page. You can also join me on FB or on G++. Please drop comments for any question related to this blog.

Comments

Popular posts from this blog

Non-virtual interface idiom (NVI)

Architectural patterns => Mud to structure => layers.

Architectural style -> Adoptable system -> Reflection.