is it good to make Data Access Layer a separate layer from service layer [closed]

Question

I am having a question about the architecture I am working with.

we have a backend restful service, a data layer(which is implemented by python eve and also a restful service), and the database. The data (access) layer itself is a independent restful api.

In our backend service application, we have a customized python eve repository which make calls to to data (access) layer and then data layer will query whatever asked by the call from database.

The reason to have it separate, one is that we want to isolate data logic(query logic) from our business logic(backend service).

The cost is obvious, another layer, another round of I/O for every query.

Can anyone with experience of architecture tell me is this separate data access layer a good practice or not and why?

Crumpler

Answer 1

Looking at architecture you are discussing in question, your project must be large enough to justify development cost of it. For small projects this architecture will be overkill.

Assuming your project is large enough, yes; it is always good to separate DAL, BLL and Application layers. Refer this and this.

The benefit is clean separation which improves understanding, given you control over each part and reduces maintenance cost.

On other hand as you said, cost is obvious (another layer, another round of I/O). Yes; that is why my first paragraph discusses about size of project. In large projects, it's a trade-off; you are choosing one over other.

In large projects, primary objective should be maintainability IMO. Understand that premature optimization is the root of all evil. So, you start with good maintainable architecture. Each technology recommends basic rules for improving performance; implement them initially. If you see any performance issue over the time, find and fix it. In fact, due to separated layers, it is easy to find bottleneck.

There are other benefits as well. You can unit test each layer separately. You can work on each layer independently for anything like improving performance, shifting technology etc. Debugging will be too easy.

Consonant

Answer 2

Basically designing a microservice architecture is good for big projects otherwise it will be a wastage of resources. But you need to consider some things before creating a separate microservice as there exist complexities like overhead time of IPC, distributed data, distribution is not free, changing the data is no longer easy as it requires coordination across different services which are that microservice (in your case data access layer). As the number of IPC can be so much that may lead to a large amount of overhead time. So the API is needed to be designed such that it will not increase overhead time significantly. The data is distributed across services so it needs to be taken care of properly.

And yes it is a good practice, the reason is simple you are doing abstraction of services. Doing so they can be developed independently as those services are loosely coupled. And even if database requirement gets changes, other services need not be bothered about it. Meaning to say, even if the whole project moves from MySQL to Cassandra or Hadoop only DAA(Data access arrangement layer) is needed to be changed, rest other services will remain the same. And also it is a lot easier to debug and test these services.

So there will always be a tradeoff in choosing a microservice architecture(One with multiple services to separate business and data logic) or a monolithic architecture(one service containing all the logic). So basically if the project is big and you are using monolithic architecture then it might lead you to monolithic hell. As the application becomes extremely large like a big ball of mud, because of which Rapid, frequent and reliable delivery becomes impossible, and technology stack becomes increasingly obsolete and rewrite is also not feasible.

Spencerianism