Looking for best practice suggestions with swagger interface. SO my lead suggests doing away entirely with the swagger interface and instead having all the swagger annotations within the Controller itself. Is this good practice or otherwise ?
This is borderline opinion-based, but yes it is ok. Some people might tell you that they prefer to have all Swagger-related annotations in an interface and others might tell you they prefer to have it directly in the Controller code. I usually have them directly in the Controller code. The only reasons to have them in an interface are to make it simpler to remove it if we ever need to and to keep concerns segregated, but let's face it how many times did you remove Swagger from a service after adding it the first time? Nevertheless, both options are ok.
Related
I do have ready the topics in the documentation, but please help me to know why this is the most correct way and what's wrong (and not enough) with methods like $this->load->model('User_model') or setting the /config/autoload.php configs in CodeIgniter?
In case we want to use additional controllers (like Request $request) as method injection, or UserRepository $users as contrustor injection (which is not a meaningful example in my opinion, but has be exampled in the main documentation) what's wrong with accessing those classes as properties (like $this->input->get('id')) or traits if we want to be committed to OOP concepts?
It more seems to be just coding style and framework conventions (which is of course important, too), isn't it?
I need to create a project able to render views (with JSP) and I need to provide a REST API too.
It's possible to have all of this in the same project?
How will the URLs works to access each things?
Thanks you!
If you are trying to follow the strict Roy Fielding-like principles of REST, then probably not.
But if you just want a REST API in a loose meaning, lets say an interface that returns a resource (JSON, HTML, a documents, etc.), sure. Think of it this way. Most web applications (ones that render views) are also going to have some form of AJAX calls, AJAX calls are just calling a REST API (~ish) that returns some JSON (or something) and then JavaScript is going to parse the response and render something on the views.
So, most modern websites that are powered by or assisted by AJAX are going to be a mix of a REST API and a view rendering one.
Hehe. I just made REST developers around the world cringe.
Now, is this a good practice? That is a whole other story. If you are talking about about a large application that is a GUI based and a large application that uses a REST API, normally you don't mix them. Things get confusing and modularity is awesome for maintenance. Also for what it is worth, normally if you are going 100% RESTful, technology you may need for UI development are no longer available since you begin to track state and such. But if its something small or UI related go for it!
As for the URLs, think about this. You tagged Spring so, I am using that.
//I will render a view!
#RequestMapping("/blah")
public String blah(Model model){
return "/view/blah";
}
//I return a JSON string of "/view/blah"
#RequestMapping("/blah")
public #ResponseBody String blah(Model model){
return "/view/blah";
}
Both of these would be inside a #Controller, they are both doing the same thing but the #ResponseBody in a very, very loose sense, makes the second a REST service, as it tells Spring that what you are returning is the response and not to render a view from it. Granted Spring will only try to render a view if you have a ViewResolver set up.
Baeldung has a great breakdown of RESTful controllers versus non in Spring, and yes they can be used in the same application.
Hopefully that helps!
Yes you can mix in an application a classic #Controller with a configuration that provides a view based on JSP and a #RestController that, as you can read from official javadoc, is a
A convenience annotation that is itself annotated with #Controller and
#ResponseBody.
Yes, you can, only have precaution about the url that you configure in your controllers, with #RequestMapping configure the correct URL for every path in your application.
Can I use this library? Or is it not desirable? And why?
I was trying to find answer, but have found nothing about this warning.
If usage of this library is not good idea, may be you will able to advise me another library.
Thanks for advance!
You can use it and I think the chances of Spring changing it are quite small, but there's no concrete intention from the Spring development team to keep that class as it's, as opposed to what they do with their public/non-internal APIs.
So if it changes in the future, the spring guys won't be accepting any complains of the type 'but my code depends on that class and you change it!.
I have looked at Spring MVC a few times briefly, and got the basic ideas. However whenever I look closely it seems to require you already know a whole load of 'core Spring'. The book I have for instance has a few hundred pages before it gets onto Spring MVC... which seems a lot to wade through. I'm used to being able to jump in, but there's so much bean-related stuff and XML, it just looks like a mass of data to consume.
Does it simplify if you put the time in, or is Spring just a much bigger framework than I thought? is it possible to learn this side of it in isolation?
#John Spring just a much bigger framework than I thought? - probably so, at least I thought so.
is it possible to learn this side of it in isolation? - Yes , here is a good way to learn your way http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/spring-web.html
And also I'd recommend you read a book manning spring in action 2nd edition, I also was learning spring from zero, and now I'm comfortable with it after reading this book, of course you have to refer to reference every now and then.
Here is where you can get basic info about MVC concept if you are not already familiar with(its in php, but important thing is point not syntax)
http://net.tutsplus.com/tutorials/other/mvc-for-noobs/
EDIT
If you want to see MVC in action, with examples or other spring uses use this repository https://src.springframework.org/svn/spring-samples to checkout some projects , you'll see mvc-basic, mvc-ajax ..etc this is really good resource , you can checkout projects with Tortoise SVN on windows or subeclipse from eclipse
At least you need to understand the core Spring - dependency injection, application context configuration and so on. It's actually not too complex, just a bit hard to start. For an experienced developer it might make sense to take a look at some sample app for the basic setup.
ps. I've got this sample project for JSF/Spring/JPA/Hibernate combination. Not Spring-MVC, but may be still helpful.
I myself am trying to learn Spring MVC from NetBeans official documentation from here:
http://netbeans.org/kb/docs/web/quickstart-webapps-spring.html
Coming from ASP.Net/C#, it feels like there are so many steps to do in that simple example.
The great thing about Spring is that you can pick and choose what you use. If you want to use Spring, you don't have to jump in head first, you can just try it out by, say, using the Dependency Injection features, or by using the JDBC Template stuff. My recommendation would be to start small, and see how you like it.
To use the Web MVC stuff, you will need to understand Dependency Injection for configuring your controllers. You can choose to use the older more flexible XML-style configuration, or you can use the newer Annotations. Or you can mix and match. Starting with XML would probably be best as it will help you understand how stuff is working (it'd be like learning C and C++ before Java). Then you can move to using Annotations. Personally, I use XML to instantiate all my beans. I use the #Autowire annotation to inject dependencies. This seems to be the sweet spot for most flexibility and ease of use.
How would one typically implement a service layer in an MVC architecture? Is it one object that serves all requests to underlying business objects? Or is more like an object that serves different service objects that in their turn interact with business objects?
So:
Controller -> Service -> getUserById(), or:
Controller -> ServiceManager -> getUserService() -> getUserById()
Also, if the latter is more appropriate, would you configure this ServiceManager object in a bootstrap? In other words, register the different services that you will be needing for your app to the service manager in a bootstrap?
If none of the above is appropriate, what would help me get a better understanding of how a service layer should be implemented?
Thank you in advance.
The way I read this question, there's really two things that should be answered:
A) I would prefer splitting "Service" into "CustomerService" and "OrderService", in other words grouped by domain concepts.
B) Secondly I'd use dependency injection to get the proper service directly where I need it, so I'm basically using alt 1. The added abstraction in alternative 2 provides no additional value for me, since the IoC container does the important part.
Using a "facade" is one way to go:
"A facade is an object that provides a simplified interface to a larger body of code"
I personally prefer #2, and yes, it would generally be configured in a bootstrap, or the dependencies would be resolved using some sort of IoC container to give you the actual concrete instances.
I would also like to comment, and yes I understand this is probably more of a personal preference. Try to avoid using the name "Service" layer for these objects. refer to them as repositories or something else. if you use service, that term becomes overloaded ... because then devs are like, "do you mean like, a rest or wcf service?". trust me, we did that with a recent project, and we confuse ourselves all the time when we're talking about where to make code changes :-P