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.
Related
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
I want to create OOP - design of network application - text chat.
I use:
Java programming language
JavaFX platform as GUI
Model - View - Controller pattern
I divided my project to 3 separate packages: Model, Controller, View.
I also created class NetworkConnection, which is responsible to create connection to the server and receive/send messages.
I have several questions about application's design:
Where should NetworkConnection class belong? Model or Controller? I have been considering make this class singleton and leave it in default package. But i heard this is not the best way in OOP - design.
What is the best way to prevent NetworkConnection class from creating several instances? If there is not, what is the best place for this class in project in terms of OOP? Since this is not an object from modeling system (such as "Message", "Contact" or "Conversation") i have no idea where this class belongs in my application.
design NetworkConnection using singlton design pattern, and it will be part of you utility which will be used in the controller.
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
I want to build an application with REST interface using Spring. The interface must be extendable at runtime: The application extends the Interface dynamically depending on unknown configuration. This configuration may change with time.
For example I have a Rest interface at http://domain.com/rest. The interface has a REST item at */rest/item which supports POST to create a new REST method. Calling POST on this REST item leads to an extension of the interface regarding to parameters given in POST request (e.g item name, properties, allowed operations (GET POST) and the code which is called by those operations). This may lead us to a new REST item at */rest/newItem.
Since I only found Spring examples using a static XML config I'm wondering...
Is this possible with spring?
Any example to quickstart this approach?
You definitely can have dynamic URL structure with Spring MVC. Take a look at path patterns. In such case you would have one request mapping with path pattern (e.g. #RequestMapping(value = "/rest/*")) and your dynamic logic.
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.