I started a project a long time ago and created a Data Access Layer project in my solution but have never developed anything in it. What is the purpose of a data access layer? Are there any good sources that I could learn more about the Data Access Layer?
I recommend you read up here: http://msdn.microsoft.com/en-us/practices/default.aspx Using a DAL will help you isolate your data access from your presentation and business logic. I use it a lot so that I can easily swap out (through reflection and dynamically loading assemblies) data providers.
Read up, lots of good info there.
Also, look into the Data Access Block if you are planning on using .NET. It can be a big help.
A data access layer follows the idea of "separation of concerns" whereby all of the logic required for your business logic to interact with your data layer (database) is isolated to a single set of classes (layer). This allows you to more easily change the backend physical data storage technology (move from XML files to a database, or from SQL Server to Oracle or MySQL, for example) without having a large impact (and if done right having zero impact) to your business logic.
There are a lot of tools that will help you build your data layer. If you search for the phrase "object relational mapper" or "ORM" you should find some more detailed information.
The DAL should abstract your database from the rest of your project -- basically, there should be no SQL in any code other than the DAL, and only the DAL should know the structure of the database.
The purpose is mainly to insulate the rest of your app from database changes, and to make it easier to extend and support your app because you will always know where to go to modify database-interaction code.
In two words: Loose Coupling
To keep the code you use to pull data from your data store (database, flat files, web services, whatever) separate from business logic and presentation code. This way, if you have to change data stores, you don't end up rewriting the whole thing.
These days, various ORM frameworks are kind of blending the DAL with other layers. This typically makes development easier, but changing data stores can be painful. To be fair, changing data stores like that is pretty uncommon.
The purpose is to abstract out the database access details that other parts of your application need not be concerned about.
A data access layer is used to abstract away the storage and retrieval of data from its representation. You can read more about this kind of abstraction in 1994's Design Patterns
The purpose is to abstract the data storage retrieval mechanism from data usage and manipulation.
Benefits:
- Underlying storage can change (switch from Oracle to MSSQL for example), and you need a way to localize those changes
- Schema changes - see above
- You want a way to run disconnected from your db (demo mode): Add file serialization/deserialization to the DAL
Data access layers make a lot of sense when many different parts of your application need to access data the same way.
It also makes sense when you need access the same data in many different ways. For example, how word processors can read many different file types and silently convert them into the application's internal format.
Keep in mind that a DAL can also be very counter productive. If you are building a system where data access performance is critical, separating it from the business logic can make some vital optimizations impossible.