What is the use of persistence layer in any application architecture?

What is the use of persistence layer in any application architecture?

 

Recently, I fell in a .NET project whose architecture was prepared by one of our senior .NET person who is architect here in .NET. I was confused with pesistence layer he had created in the application architecture. I searched it on google but found on consolidated answers from anywhere. At last I came to get help from Stackoverflow .NET experts. I asked following question on stackoverflow and got valuable responses.

 

My question on persistence layer architecture:

 

I have to create an application in which I am asked to create an persistence layer in the application. The application is in .net. I have created business layer and presentation layer but I don't know how and why to create persistence layer.

 

I googled and came to know that persistence layer is used for storing and retrieving data usually from a database.

 

Can anybody explain in detail?

 

Responses I got:

 

Davide Piras Response which I accepted later on:

 

The reason for you to build a DAL ( Data Access Layer ) or any other kind of intermediate layer between database engine and Business / Application logic, is that by adding this layer in the between you isolate the rest / upper layers of your application from the specific database engine / technology you are using right now.

 

This has several advantages, like easier migration to other storage engines, better encapsulation of database logic in a single layer ( easier to replace or modify later depending on how well you have designed your cross-layer interfaces etc...)

 

See my most rated answer here, it is an example about ASP.NET MVC and EF but the structuring of solution and projects is actually technology independent: MVC3 and Entity Framework

 

Also read some articles to better understand this matter, for example: http://www.developerfusion.com/article/84492/net-and-data-persistence/

 

Renan's Response

 

If you're not saving your data somewhere, it won't be there again when your app is opened again. You can save it to a database as you said (SQL, Oracle, PostGRE etc.), or directly to disk (serializing in binary format, or plain text etc.).

 

Using a layer to do that is a good practice. It reduces coupling (i.e. spaghetti code), and makes maintenance much easier.

 

I suggest you read about Hibernate and it's .NET cousin, NHibe

 

Kenneth Garza's Response:

 

Persistance layer otherwise known as a Data Access Layer or other terminology.

 

It seperates the guts of getting and saving the data from the business layer. The reason you do this is so your business logic (the part of the application that does the heavy lifting for your data manipulation) is not tied to a specific type of data source.

 

The data layer will need to be written to be database specific. So if you're using MySQL to access all your data then you will write the dataLayer for that use.

 

If at some point you decide to move to MongoDB, then instead of rewriting your entire application. You can rewrite just the data access parts to get the data from MongoDB. Since the business logic doesnt care how you get the data, only that you do, it and the Presenation layer can remain intact.

 

Hope this helps.

 

Belogix Response:

 

In very simple terms a persistence layer is a way to SAVE and RETRIEVE items that your application uses.

 

A simple example is you have a class that represents a person (name, age and gender). While your application is running this is held in memory. But, say you want that information available if you close and open your application again. Well, you need some way to SAVE that person and then later on RETRIEVE it again. This is where a persistence layer comes in and will write your person somewhere "permanent".

 

That could be a database, a flat file, registry depending on the life-time and requirements etc.

 

In your persistence layers you will perform CRUD (Create, Read, Update, Delete) operations. Often against a database so you would Create a new person (Fred Bloggs). Say they change their name another user of your system might Read the record and change to Fred Miggins and Update the database. That customer then leaves the country so you Delete them.

 

Please refer to stackoverflow page for details.