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

Question

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 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/

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

It separates 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.

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.

Persistence = read/write/delete records to disk or database.

Layer = insulation, etc.

Persistence Layer = generally means to isolate read/write/delete logic from the business logic. ideally by placing a few (or a single) point of interaction between the business logic and the persistence modules.

I think its something we've all done (save to disk, db, etc), this is just a fancy academic term, they're just asking us to:

1. make sure that the persistence parts group together nicely,
2. ideally with few (or exactly a single) point of interaction inbetween business logic (ie. gateway pattern),
3. so in the future maybe we'd like to switch database types or hosts (i.e. smaller scope - we'd just need to muck around the persistence parts to get it running).

Cheers,