Menu
We have 3 layered application where every call from the service layer goes to the business layer and is persisted by the data layer. Components of each layer can only call the layer below;
However because we have hundreds of entities and we have lots of services related to crud operations so many controversies raised on our team.
Some believe for the sake of maintenance and ease of development it's better to call data access from crud services which just doing crud operation and bypassing business layer.
On the contrary some saying we have to create wrapper for data access of each entity in business layer and call these wrapper from services and never allow services to call data access layer.
In your idea which way we should take? Is it ok for crud services to call data accesses and bypassing business layer?
472
For example, a presentation layer would be responsible for handling all user interface and browser communication logic, whereas a business layer would be responsible for executing specific business rules associated with the request.
Business Layer elements are used to model the operational organization of an enterprise in a technology-independent manner, whereas strategy elements (Chapter 7) are used to model the strategic direction and choices of the enterprise.
The Service Layer is usually constructed in terms of discrete operations that have to be supported for a client. For example, a Service Layer may expose Creating an Account. Whereas the Business Layer may consist of validating the parameters needed in creating an account, constructing data objects to be persisted, etc.
As I understand it the business layer is in charge of the business decisions AKA the logic involving the protocols of the client. The application layer are the raw processes that have nothing to do with business decisions.
A multi layered software architecture still has the presentation layer and data layer. It simply splits up and expands the application layer. These additional aspects within the application layer are essentially different services. This means your software should now be more scalable and have extra dimensions of functionality.
This is a good place to start because all layered software architecture contains these three elements. These are the foundations: Presentation layer: This is the first and topmost layer which is present in the application. This tier provides presentation services, that is presentation, of content to the end user through GUI.
Therefore Business Layer methods adds/inserts new data into the in-memory data classes or simply changes any loaded data from the database. However the Business Layer never calls EF’s SaveChanges. That is done in the Service Layer that called it.
This type of layered architecture is known as closed layer architecture. If done right, a closed layer architecture reduces couplings in an application. For example, suppose in the Educator Tools application, we want to switch the ORM framework from Entity Framework to Dapper.
If there is no business logic to perform, there is no reason to enforce a business layer. The 3-tier architecture is not an arcane protocol, just a best practice that was formed assuming business processing.
In a current application we are often accessing DAOs directly from JSF controllers when there is no business process involved. The idea was given by a java champion who stressed the idea that simplicity is paramount.
If you are worried about future modifications that may require adding business logic. I think of the issue this way: The additional business logic would be added to the business layer anyway, including data access, so there is no difference here.
CRUD code is mostly very simple. So the change in the service would amount to reroute a single call or a couple of calls fron the DAO to an EJB - a simple refactoring. The CRUD code itself would still remain, but will be pushed into the EJB - another simple refactoring.
This is not perfect, but IMO better then the alternative: having an empty indirection layer. This adds complexity that serves no purpose. The business object would do nothing but forward the calls to the DAO.
There are two code smells that I think apply in this case: contrived complexity and feature envy.
I am not saying that DA in the business layer is somehow a code smell. What I mean is that having a business object that does nothing else but proxy the DAO is a smell. It's the same with complexity - an added data structure / architectural layer that serves no own purpose - there seems to be a DAL in your application already.
Another aspect for your consideration would be - how surprising is it for a developer to see a service that uses a DAO directly? Having 5 services where 2 of them access DAO directly is different from having 100 services where only one service accesses the DAOs directly.
In the first case the code simplicity would outweigh the added conceptual complexity (2 concepts for a single thing), in the second case, I would rather stick with the business layer - the surprise (also called the WTF-effect ;) of doing it differently just once would be too big.
137
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
