What is the ratio in defining multiple controllers (in Spring MVC) instead of just one that matches all paths?
Could you write me also a use case scenario?
Following the suggestion of #Lyju, the number of Controller in a Spring MVC application is a personal choice, but it is better to follow the single responsability principle: every module should have responsibility over a single part of the functionality provided by the software.
For furhter details:
https://en.wikipedia.org/wiki/Single_responsibility_principle
Related
I have the below question asked in the interview but could not able to find any straight answers to the below questions.
What design pattern do we follow while creating the REST API in Spring boot application?
Microservices uses which design pattern?
for your question one, we're using the (MVC) pattern to create a REST API but in the REST API we're not using View instead we're using a JSON responses, and also other patterns that may be used while building REST API including Command Query Responsibility Segregation (CQRS) pattern, its also worth to be mentioned that Microservices also use this pattern which we mentioned now since the Microservices uses an architectural style that involves building a large, complex application as a collection of small, independent services, The design pattern that is commonly used when building microservices is the Command Query Responsibility Segregation (CQRS) pattern because This pattern involves separating the responsibilities of reading and writing data into separate components which gives single responsibility to the component as they already are.
The questions that the interviewer has covered are fairly broad questions. Anyway, I believe that it is important to show your basic knowledge based on the Spring MVC pattern, and how the embedded Tomcat Servlet container in the Spring Boot operates. (So basically it is the main role of the Spring Boot Controller)
In the Spring MVC, you use various controllers to handle HTTP requests and create REST APIs, by adding spring-boot-starter-web dependency. This dependency includes some key libraries including the Spring MVC framework and the Tomcat servlet container. Then, you got two options either #Controller or #RestController, to create your own servlet for your web application.
Since the interviewer is asking about REST API design, I would prefer to use
#RestController, because this annotation is capable to produce RESTful response entities.
As for the second question, I am prudent to answer it, because Microservice Architecture is a type of "Architecture Pattern", which is a more complicated and sophisticated backend structure for the business service. Overall, I believe that the Event-driven design pattern is a good option as a fundamental one for implementing a successful MSA.
In the MSA, the event-driven design pattern is useful for enabling communication between different microservices projects. Because microservices are designed to be small, independent, and loosely coupled, they often communicate with each other using asynchronous messages(a.k.a. events). By using an event-driven design pattern, you can create a publish-subscribe model of communication between microservices, which can make it easier to scale the system and add new microservices over time.
BUT don't forget that MSA contains various design patterns that are useful as well!
I have a use case where I would like build a common interface or service which can update entities of application. Example case is shown as below:
Now every application has to handle update functionality of entities. Rather than implementing update functionality in n application module. I would like to build a common interface or server in spring boot.
Service will be like below:
My question is how to design service/interface which can used for above scenario. Any api or tool which can help me to achieve this. I dont want to write code for update in every application module.
Thanks in advance.
Last year I was thinking about the similar concept to yours, but in Apache Camel framework context. I haven't got enough time and motivation to do so, but your post encouraged me to give it a try - perhaps mostly because I've found your concept very similar to mine.
This is how I see it:
So basically I considered an environment with application that might uses N modules/plugins that enriches application's features, i.e. processing feature etc. Application uses module/plugin when it is available in the classpath - considering Java background. When the module is not available application works without its functionality like it was never there. Moreover I wanted to implement it purely using framework capabilities - in this case Spring - without ugly hacks/ifs in the source code.
Three solutions come to my mind:
- using request/response interceptors and modifying(#ControllerAdvice)
- using Spring AOP to intercept method invocations in *Service proxy classes
- using Apache Camel framework to create a routes for processing entities
Here's the brief overview of POC that I implemented:
I've chosen Spring AOP because I've never been using it before on my own.
simple EmployeeService that simulates saving employee - EmployeeEntity
3 processors that simulates Processing Modules that could be located outside the application. These three modules change properties of EmployeeEntity in some way.
one Aspect that intercepts "save" method in EmployeeService and handles invocation of available processors
In the next steps I'd like to externalize these Processors so these are some kind of pluggable jar files.
I'm wondering if this is something that you wanted to achieve?
link to Spring AOP introduction here: https://docs.spring.io/spring/docs/5.0.5.RELEASE/spring-framework-reference/core.html#aop
link to repository of mentioned POC: https://github.com/bkpawlowski/spring-aop
I've read the post MVC With Lazy Loading and i still have some questions:
If we use the 4th choice, which part should be in charge of the transform process? The controller or the service? If we use controller, is it good to introduce #Transactional to controller?
I also see a post that suggested to use different query for different usage. It seems like to use different fetch groups JDO fetchgroup for different purpose. Is it good to use this way?
Thanks.
In today's day and age you can and should expose services as REST controllers and return proper domain objects rather than ModelAndView or other such constructs from Spring MVC.
UPDATE: Clarification: There is NO controller class in this approach I am suggesting. Expose Service as #Controller. Expose public methods on service as REST and annotate transnational, authorization etc context on the method. Because from an API point of view this public interface serves all kinds of clients whether it is REST or direct method call.
Also if you have dedicated controllers and services you may see some business logic seeping into your controllers in no time.
I would go to even further and not use option 4 which is essentially leads to a DTO anti-pattern.
Having said that it still depends on the complexity of entities. A very complex entity with many association is going to be a performance hog due to the queries it fires. Yet your MVC (JSPs) may actually resolve the associations whenever needed. (In a side note with full REST full architecture this is an issue.)
What is the difference in using AbstractWizardFormController OR Spring Webflow. How should one decide which one to use in a given scenario.
EDIT:
Is there any benefit of using one over the other?? Does Spring Web Flow provide additional advantages? I am a newbie in Spring and therefore am not very sure of what each of these provides.
Thanks!
AbstractWizardFormController is deprecated. For that reason alone, I suggest not using it, and either use standard annotated Spring MVC controllers, or using WebFlow. Which you use depends on the complexity of your flow.
The wizard form controller is Spring 1.0 vintage; web flow came afterwards. I'd say web flow should be preferred, unless your flow is so linear that the simplicity of the wizard is compelling.
Ok, this is kinda dumb. I'm trying to wrap my head around the use of
the MVC and Command Patterns. The questions basically concern where to
place code.
In the MVC pattern, where are the Commands instantiated?
Are they created by the Controller, or are they contained fully in the Model or neither.
BTW, Should one be using the Command pattern if there is no need of undo/redo.
Regards
While there are many variations based on the needs/complexity of an application, you typically find them implemented in the Controller. Here is a great article on using the Command pattern in an MVC architecture. I'm not sure what type of application you are building, but here are a few more resources that show implementations on different application stacks.
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web-tier/web-tier5.html
http://msdn.microsoft.com/en-us/library/ff647590.aspx
http://www.phpwact.org/pattern/model_view_controller
To implement Command pattern in an MVC application depends on your specific need. Controller does not create any Command by default. If you need to implement command pattern in a MVC application you have to do it on your own.
You can either implement the commands in the Controller or can do in a separate Service layer. It should not be in Model as Command pattern is behavioural and should be independent of model.