In a previous article about “Layered Software Architecture Part 1″ I shared my thoughts about it isn’t enough just applying any of the MvC, MvvM or MvP patterns to build a good Software Architecture.
For non CRUD applications where there are business logic in the app I think it’s a good idea if :
- Api Rest (Communication) Layer shouldn’t have business logic neither have access directly to the Data with an ORM.
- Api Rest (Communication) Layer should only limited to have simple data validations.
- Business layer should avoid to have direct access to data via ORM or SqlQueries since the Data Access Layer is the responsible
- We should try to build thin Api Rest (Communication) Layer and fat Business Logic Layer
Here below we have a list of points of what I think it should be done in business logic :
- Execute the business logic: processing the command raised by the Rest Api to execute a process or workflow
- Execute the Business Process or Workflow :to perform calculations or rules
- Execute the Business Rules : to make logical decisions from the business process
- Request to the data access layer the data models to be used by the business rules
What I think it shouldn’t be done in the business layer is:
- Get data directly from the database in the BLL
- should not care where it gets its data from
Does your Business Logic Layer have direct access to the database using an ORM/MicroORM (“EF DbContext”)/(“DAPPER queries”) and the BLL don’t delegate to Data Access Layer to do the retrieve of the data ?
If a business layer get access directly to retrieve the data from the database then the business layer is transforming something like a business logic data access layer so Don’t you think that it isn’t breaking the single responsibility pattern ? because it’s working with the data base.
In the below diagram we can see a simple draft of a possible simple software architecture with communication between layers and responsibility
When a business logic layer is not couple to the data access layer them it will be easily tested with easy implemented unit tests without complex mocks otherwise it will be become hardest.
I don’t think building a huge list of business layers is the best approach and I think at least it could be enough having one BLL layer which will group (Business logic, Business Rules, Business Processes)
From my point of view a Business Layer Logic should have the RESPONSIBILITY to execute the business logic , also BLL will be the intermediary between the Data Access Layer and the Communication Layer (API Rest)
Doing a good separation will be easier be possible to scale the application doing something similar like in this example :
Do you think that sometimes it could looks like we’re doing a double wrapping and waste of time when we don’t use directly the ORM in the BLL ? Please share with me your opinion/ideas or any other interesting resources {url, articles, code} via twitter or this blog 😉
Does your Business Logic Layer have direct access to the database using an ORM/MicroORM ("EF DbContext")/("DAPPER queries") and the BLL don't delegate to Data Access Layer to do the retrieve of the data ?
— Jesús Estévez (@jecaestevez) March 18, 2018
Tweets related with this topic:
As always: it depends A LOT on your reqs. Generally a strong: NO, if you want (and you should) to unit test your BLL, Better use a DAL + DI. Resolving a performance bottle-neck, or when doing code-gen for CRUD simple Services with no real Logic, it could be YES, for example.
— Pedro J. Molina (@pmolinam) March 18, 2018
Images source:
Diagram generated with https://www.draw.io/
scale app using vm
No silver bullet by @bryanMMathers i
Geek and Poke’s Footprints – Licensed CC-BY 2.0
Responsibility image by Nick Youngson CC BY-SA 3.0 Alpha Stock Images
interesting articles:
N-tier architecture style
N-tier application architecture