Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
In J2EE design, usually we have view layer, business layer and dao layer. In business layer, if we need some other data, shall we call the DAO directly or call the other data's business service?
I like this question, because I had to find the answer, and later convince the others... So my view, coming from experience on some projects is:
Business Layer should be built from Componenents (I would name them Facades) which are responsible for some tasks. E.g.
Validate Entity/Object before it is persisted (DAO is called) (kind of Persist(entity))
Or represent factory method CreateNew(), returning new objects with some basic business settings (pre-filled country, currency...)
load some data via Find(filter)
And I could continue, but at the end, I would end up with Facades, which are really doing their tasks and are responsible for them. And that means that we have the answer.
If there is already some business object (Facade) representing some specific task... other business componenets should use it. They should not reimplement it again.
To say it clearly explicitly:
Other layers (presentation, scheduled job) should call only one Business API (service/facade)
This Business Service/Facade should do its job, and if needed it should call other Business Service(s)/Facade(s) and ask them to do their job.
That service should NOT call DAO if this is already implemented elsewhere.
So if there si some BL guy, ready to get data from DAO or pass (and validate) some other data into DAO ... we should use it...
At the end, we have DRY and SOLID principles in place... and code becomes easy to maintain and extend. For example, if we know that there is only one EmployeeFacade.Find(filter), it is easy to introduce AOP and be sure that all the results could be intercepted...
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
In order to understand the following question you need to know that I'm a complete novice in the whole Spring Boot ecosystem, as well as, the architectural philosophy behind it.
Task
The app I'm developing with Spring Boot requires, on a business level, some data which are simple collections stored in Firestore. Now, the user when inputting some parameters on the front end (the REQUEST method) and asking for the execution of a certain algorithm on the back-end will trigger the following:
1. The business logic part of the app is going to retrieve some data from the database based on the user input.
2. It's going to process this data and create a RESPONSE based on the retrieved data and a number of other user input.
The problem
So, I'm not really sure if I should be even bothering with creating a service connection for the database since the only one accessing it will be the business logic layer. The database will primarily be build for reads only while at the same time I want to leave open the possibility of later creating a system for auto-updating it (again, only from the back-end, no user interaction/input). Also, what I'm possibly forgetting is the support for multiple connections. Each user may trigger the main algorithm to run utilizing a different set of data retrieved from the database. In that vein, while I would love to leverage the capabilities of Firestore, is the use of it justified in the sense of the data being static for the time being?
You should strive to keep the business logic as pure as possible from implementation choices. Ideally your business logic should not talk to network, file systems or databases. It should be just the pure, refined business logic.
You will then have outer layers that abstract as much as possible these external dependencies. In the case of database, usually you'd have a persistence layer of sorts, which is responsible for accessing directly the database.
For instance, lets say the business logic needs a list of clients sorted by last name. From the business perspective, they're calling a method fetchClientsSortedByLastName() and what that method does is a black box. If at a later moment you decide to switch from Firestore to Postgres or Mysql, you only need to change the persistence method. The business logic will remain exactly the same.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Recently I started thinking about #Transactional and how it works and the performance and I have a project where I use spring transactions, so I have such code:
#Transactional
public PageableProductsDTO getUsersProducts(String userName, Pageable page) {
PageRequest pageRequest = PageRequest.of(page.getPageNumber(), page.getPageSize(), Sort.Direction.DESC, "createdAt");
Page<Product> pagebelProductsByUser = productRepository.findProductsByUser(userService.getUser(userName), pageRequest);
Page<ProductDetailsDto> productDtos = pagebelProductsByUser.map(source -> {
ProductDetails productDetails = source.getProductDetails();
return new ProductDetailsDto(productDetails.getBarcode(), productDetails.getName(), productDetails.getPrice());
});
return new PageableProductsDTO(productDtos);
}
As you can see, in the above method I fetch products from db, and then map the products to the PageableProductsDTO, I have doubts whether I do it right, because maybe the dto mapping should be done in controller layer? And also it seems that doing such mapping in the service layer will prolong time spent for transaction itself, I mean maybe it's not good in perspective of performance?
There’s no universal solution, only the one that suits you best. It’s not about DTOs being pattern or anti-pattern, it’s about do you need them or not.... and why
One part of the question is if you should re-pack data in controller or service layer. That depends fully on if you introduced DTOs to separate data and business logic of your application layers OR you introduced DTOs to re-pack data (maybe remove some private properties) that will be returned to the client (if latter is the case, controller should do the business).
Although performance impact looks negligible in this case, you should1 move logic of loading data from DB in separate method and mark that one2 as Transactional.
1 Separation of methods will allow you to re-use code that loads data from DB inside service layer, without need to re-pack data back to entities.
2This will be good pattern as long as you want to commit a transaction after executing db load. If you want to re-use method for loading data from DB please consider other use-cases and if you want to prolong committing.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
All of the examples I've read about DAO classes only show DAO classes with very general methods, for example, insertNewCar(), deleteCar(), updateCar(), getCars(), getCarByID(). But can I put more specific methods into a DAO class?
In my case, I need to get all doctors who are having a shift today, and to know that, I have to get all doctors' scedules which have the date equal to today. Right now, I'm getting those doctors by a single method in doctorDAO class called getDoctorsWorkingToday(ArrayList scedulesToday). In this method, I first get all ids of doctors from the arraylist and attact them into a complete sql query. And the rest of the method is just like a normal "get" method: I use the query to get all doctors I want, put them into an arraylist and return it.
It works fine, but is that solution acceptable? Or must I only use general methods in DAO class like getAllSchedules() and getAllDoctors(), and do all the filter stuff in other classes?
As per my understanding , I usually put all db specific code (queries) in DAO's and transaction handling and business logic in service layer. This allows for service methods to invoke methods across multiple dao's and keep it all within same transaction. In my opinion, this is allows for better code reuse across dao's.
In your case,
Use 'get' method business logic in Service layer and Query related stuff in dao.
It's upto you, how you are implementing the service and dao. Just for the flow and easy understanding,we are following the standards.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
What exactly a Business Logic is?
In MVC which part consists Business Logic?
Is that service part of MVC works as Business Logic(for example CRUD operations)?
what is the better(or best) approach to implement Business Logic in Web applications?
1.Business Logic:The overall set of rules that determine how the data will be stored or manipulated in a business or application domain.
2.The Model-View-Controller (MVC): An architectural pattern that separates an application into three main logical components: the model, the view, and the controller. The data associated with the underlying business logic is represented by Model. The UI logic of the application is represented by View layer.The Service layer or Controllers act as an interface between Model and View components to process all the business logic and incoming requests, manipulate data using the Model component and interact with the Views to render the final output.
3.The service layer or controller infact represents the core business logic for the data manipulation represented by CRUD operations.
4.For larger web applications the best approach is to keep minimal amount of code in each layer and a seperate layer is added centered around the business logic. This layer is termed as a business logic layer. For smaller applications the database objects itself could contain the business logic.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
So the question. We use service to worker pattern and now are looking for an appropriate pattern to transfer data from controller to view. Any help is appreciated.
Unfortunately I couldn't attach diagram at first (it's a cool site,isn't it) as I didn't have reputation 10 and thanks to people now I can
Comment:TemplateEngine is any alternative to jsp template engine.
So I will try explain via text.
Classes:FrontController,Controller,View,Action,Jsp files, EJB, Entity (Anemic Model). So FrontController routes to Controller and invokes two methods of Controller by order. Controller has only two public methods processAction and processView. ProcessAction invokes Action (command pattern),so
FronController calls Controller.processAction()->Action -> EJB - >get Entity.
So here the FrontController must invoke the second method of Controller
FronController calls Controller.processView()->View -> Templating, jsp , helpers etc(at this point we need data that we have got in controller)
EDITED:
Controller.ProcessAction and Action.execute have the same signature:(HttpServletRequest request, HttpServletResponse response).
What about request/response object(context object). I've read core j2ee patterns and was surprised. As I understood this object takes data from request and even makes validation. Its main goal is to give as a tool to work with data that removes the dependency of different protocols (html,xml,json). There are two reasons why I was surprised:
Context object was created in frontcontroller - at this step we can hardly define that context object we will use. Often there are situations what we even need another controller.
I think that validation must be performed in EJB. The reason is very simple if we have two kinds of clients: browser and java application than their common point is EJB. So it's in the EBJ we must make validation.
So, I am very interested in other people's opinion.
I think that you can have GetData() in one controller, combine the GetData() in TemplateEngine layer. Or, another approach, is to add one more layer Service layer, to retrieve all the data, and controller will combine all the GetData() functions from service layer.
Thank you,