Data access layer helps us to isolate our code from presentation layer and business layer. We use data access layer to pull data from different data stores (database server, flat files, web services, whatever else). This way, if you have to bring any changes to your data layer for example we want to replace ORM, Database server or add web service repository to retrieve data. We wont end up rewriting the whole thing.
These days, various ORM frameworks blur the boundaries between different layers. This typically makes development easier and cuts development time, but it can cause a lot of problems as demand on application grows and we end up with spaghetti code. To be honest, changing database servers is very uncommon.
Basically there are two main reasons why we should use Data Access Layer.
It help us abstract the actual database or other data providers from our applications and that makes it easier to switch from using MySQL and moving to MS SQL server. On Business Layer side we can abstract the logical data model from our Business Layer making it loosely coupled and it also makes business layer agnostic about data access. Giving us the freedom to modify the data model without impacting the business layer.
Another reason our business layer should not be aware of the logical data model used by our application, is to allow changes in our business layer without having any effect on our physical data model. Lets take an example at some point in time in our applications life we need to retrieve data from third party web API and use it in our business logic, if our Business Layer is agnostic about data and how and from where it is retrieved, this allows us lot of freedom to improve or enhance our application. Modern tool sets like ORMs and Linq make life a lot easier which, in my opinion, encourages developers to cut corners under pressure to deliver applications quickly and tend to forget (or are not able to implement the separation between different layers that should exist).
Essentially, to get a better understanding the reasons and function of a Data Access Layer, you need to see things from Presentation and Business Layer's side, keeping in mind that presentation layer should be agnostic of business layer and business layer should be agnostic of the data access layer.
A data access layer follows the idea of "separation of concerns" whereby all of the logic required for your business layer to interact with your data layer is isolated to a single layer, as shown in the image below.
The reason behind me blabbering about Data Access Layer is because time and again colleagues and others were very adamant that data access frameworks, such as Entity Framework acts as Data access layer and (EF) which follows the repository pattern and it is acting as a data abstraction layer. But, I hold a different opinion and I think ORMs have its place but they can make your application very inefficient if we fail to use them effectively. Some of the performance related issues are well known, for example:
Majority of the time when I migrated a legacy application it was normally a big fat monolith and the most of the Linq statements were DataContext.TableName.where(Some Condition EqualTo) which basically translates to (select * from table where condition) In reality we may only need two fields from a table that has 100 fields.
In order to do a delete or update, (EF) first select the record and then fire a query to the delete or update.
3) ORMS tie your business layer very closely to the data model, defeating the whole concept of "Separation of concerns" and reason why we should have a data access layer.
I personally always implement a class library in my data access layer where I can write SQL queries which are a lot more efficient as compared to Linq, especially when we need to retrieve a large set of data from several tables. You can call it a hybrid application which make use of EF and SQL.
Top comments (0)