Why does all dependency injection in ASP.NET MVC3 happen at the controller level instead of at the action level. Controller creation is typically overridden in order to inject dependencies when the controller is instantiated. However, the controller is only instantiated as the result of a request for an action. Why not handle the dependency injection at the action level?
Because this is a known pattern and the hooks are in place in MVC to inject into a controller, not an action. There is a controller factor, but not an action factory. You create an instance of the controller, not the method, so thats where the injection needs to take place.
Plus theres a known pattern of constructor injection which would be more appropriate here than some other method (i.e. action method) injection and it also allows any other setup in your constructor that may be necessary.
You could use model binding as an action method injector of sorts. Here's a little introduction to model binders you can read:
http://www.singingeels.com/Articles/Model_Binders_in_ASPNET_MVC.aspx
You could instance and pass repositories, or anything you'd like to the action methods in this way, and it'd be reusable.
My guess is that you are starring at a GOD controllers with 10 dependecies and a lot of actions and wonder how this could be made better?
Remember! Controllers should be skinny and contain few actions. I prefer my controllers to only have one action per HTTP method.
Related
I am actually a EJB developer and very new in spring framework.
i find a couples of conflict conceptually. Like ..
#RestController use by default scope which is singleton. By single object per loc have to manage heavy trafic.
is it a good design?
Of course, it is a good design because the same instance of the object will be reused instead of keep creating it each time you need it. That is the whole point of that design pattern.
Here is a great example where singleton comes to the rescue.
https://rules.sonarsource.com/java/RSPEC-2119
By default, spring will take care of the creation and destruction of all singleton beans, while the prototype has to be manually handled. Therefore in a lot of cases prototype scope is for custom beans made by developers.
In SpringMVC Controller layer, #Scope("prototype") vs #Scope("singleton")
is it a good design?
Yes, all beans in Spring are singletons (by default).
We have 100+ controllers in several applications and it works perfectly.
If you really need to instantiate controllers more than once, you can, of course, consider other bean scopes (see brief explanation of scopes here https://www.baeldung.com/spring-bean-scopes)
I have a short question. I know i should annotate a service with #RequestScope or #SessionScope if i want to prevent race conditions and other thread related problems from occuring while handeling multiple incoming requests. But should a Controller have such an annotation as well or should a controller always remain a singleton?
Thank you
Not really. If your intention is just want to prevent race conditions due to concurrent requests ,you can still achieve it using singleton. Just make sure it does not contain any instance variables which contain some state and controller method will modify these state. In practise , it is very common to inject a stateless singleton service into a singleton controller. Theoretically , the singleton controller should have the best performance as it does not need to be created every times.
What scope to use actually depends on the use-cases. For example, if you are implementing a web-based shopping cart , you definitely need to look at the session scope controller such that items added to the cart will not disappear between two HTTP requests in the same session.
My experience of implementing the RESTful web service is that I only use singleton controller as one of the characterise of the RESTful web service is stateless.
Researching the use of inheritance in Spring MVC.
Is it a good idea to have a base controller that other controllers can extend ?
The base controller would be to hold functionality common to all controllers.For E-g getting a handle to the logged-in user etc.
If using the base controller is not a good idea are there any other suggestions to implement something like what I have mentioned above.
It is perfectly acceptable to have a base controller that other controllers can extend. When Spring introduced #Controller annotations, they paved the way for you to use whatever class hierarchy you want.
Just be aware that as an object oriented design principle, it's good to favor composition over inheritance. As a rule of thumb (not a hard and fast rule) I would recommend moving your common controller code into a class whose interface can be injected into your controllers via #Inject or #Autowired.
Another suggestion for getting a handle to the logged-in user is a little more work but very nice once you have it. See the discussion here about using a current user annotation on your controller method arguments. This is what I do on my project and it works great!
These days i am learning spring by http://static.springsource.org.
I am facing some problem in this page http://static.springsource.org/docs/Spring-MVC-step-by-step/part4.html. i am not getting it clearly that when setProductManager method is called when InventoryController class is invoked. I know that this works as a front controller and when hello.jsp page is requested ,ModelAndView method is executed of InventoryController. but i want to know that when setProductManager method is called.
Any help would be appreciable.
Spring is an ioc container and in this particular example the dependency-injection is implemented using setters (setter injection). Basically the container takes care of supplying your bean (controller in this case) with necessary dependencies.
Back to your question: dependency injection is performed before your bean is ever used by the framework or any other beans requiring it. Furthermore, controllers are singletons. This means setProductManager is called before any request is handled by the controller - when the application is started. And because there is only one instance of the controller - it is called once.
I am using the NuGet add the Ninject and Ninject.Web.Mvc reference to my project.
but i don't add register code for the controller(with a parameter constructor) binding. but it seems the controller was created correctly, i wonder how Ninject create the controller with dependency parameter withou register the controller to the ninject.
in the Ninject.Web.Mvc, and i found the following sentense in the author (ninject) 's blog,
The controller itself will be found by Ninject even without adding a binding. Of course, you can still add a binding for the controller in case you need to specify more information for the binding (e.g. an additional constructor argument).
i found a similar questions,
How does Ninject create controller in ASP.NET MVC?
the answer saids:
Ninject finds constructor for this type, injects parameters, returns controller instance
my question is : if we don't register the controller how did the NinjectResolver resolve the controller?
non-abstract classes (such as controllers) are resolved by ninject by default as Bind<TheType>().ToSelf() if there is no binding.