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?
相关问题
- What do we call the combined path, query, and frag
- “Scraping” vs. “Scrapping”: Is there a difference?
- What is the correct term for _ in a type hint?
- Is returning DataTable or DataSet from DAL is wron
- C#: Services access the dataprovider class running
相关文章
- What does “exposition only” mean? Why use it?
- “Adapter” or “adaptor”?
- What is {{$guid}} used for in Postman?
- How to manage SqlDataReaders in a data access laye
- What is a bit field in layman's terms?
- Is it possible to stub Entity Framework context an
- Guidance needed ASP.Net app connection string
- How to effectively Unit Test a DAL that uses ADO.N
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.
There are two primary purposes of a Data Access Layer
Abstract the actual database engine or other data store, such that your applications can switch from using say Oracle to using MS SQL server
Abstract the logical data model such that your Business Layer is decoupled from this knowledge and is agnostic of it. Giving you the ability to modify the logical data model without impacting the business layer
Most answers here have provided the first reason. In my mind it is the second that is far more important. Essentially your business layer should not be aware of the logical data model that is in use. Today with ORMs and Linq #2 seems to go out the window and people tend to forget (or are not able to see the fine lines that do and should exist) about #2.
Essentially, to get a good understanding of the purpose and function of a Data Layer, you need to see things from the Business Layer's perspective, keeping in mind that the Business layer should be agnostic of the logical data model of your data store.
So each time the business layer need data for example, if should ask for the data it needs in a very simple logical data model agnostic way. So it would make a call into the Data Access Layer such as:
And it gets back exactly the data it needs without being aware of what tables store this information of or relationship exists etc.
I've written an article on my blog that goes into more details.
The Purpose and function of a Data Access Layer
Something which hasn't been brought up that I thought I'd add is that having a DAL allows you to improve the security of your system. For instance, the DB and DAL could run on server(s) inaccessible to the public while the business logic can run on a public facing server such that the public server can't run raw SQL on the DB. This could help mitigate a lot of damage should the public server be compromised.
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