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.
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 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...
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 8 years ago.
Improve this question
in mvc what comes under what? beans, servlet and DAO. Where these tech will fit in the mvc. what will come under model, view (like jsp,html) and controller
Model: Any object that has values that need to be displayed in a view. These can be domain models, simple pojos, or anything else really. But typically the objects hold data that needs to be used in the view.
View: The thing that actually displays information to a User. In your case the JSP/HTML is considered the view. Note, a User does NOT have to be a human being.
Controller: Used to determine what Model needs to go to which View. In your case the servlet should be considered the controller.
DAO is actually part of the persistence layer, but generally it is ok for a Controller to access objects in the persistence layer and query them. You just don't want a controller writing data to a DAO. That is what services are for.
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 8 years ago.
Improve this question
At the moment I have a zoom method in a View class which resizes an image being displayed.
Should this logic be in the View or inside the Controller ? Why so ?
The problem with putting it in the view is that the view in (at least some) web frameworks is implemented as little more than a template file and a mechanism to inject values into it. This doesn't feel like a suitable place in practice, since doing so would mix business logic with presentation, which in turn would defeat the purpose of using a framework in the first place.
If your application is re-rendering an image prior to outputting it, perhaps you could create a service class that carries out this function, and then call that from the controller. That way you avoid putting logic in your presentation layer, and you keep the resize logic separate from the web context of the controller, which increases testability.
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,