I am trying to inject a UnitOfWork into my repositories using Guice in Play. I am trying to configure the UnitOfWork to be RequestScoped, but there does not seem to be a way to do this.
I have googled and been on stack overflow for a while now and have not come across a clear answer for this. What is the state of RequestScoped for Play in 2019?
Play Framework is Stateless by default. From its Web Page:
Play is based on a lightweight, stateless, web-friendly architecture.
So everything that you inject with Guice is created newly.
There is an exception if you annotate a class with Singleton then this class will be injected only once per Node.
Related
All,
There has been a lot of posts about Unity Lifetime Managers but I have yet to find someone state a good rule of thumb for "in these cases you should always use X". Let me describe my application, I have an ASP.NET MVC 4 Web Application. I have a Visual Studio solution containing 3 projects, my 'Core' project which has all of my EF stuff, a testing project, and the MVC Web Project. I am using Unity for dependency injection and have the following code right now:
// Context
container.RegisterType<IDatabaseFactory, DatabaseFactory>(
new ContainerControlledLifetimeManager();
container.RegisterType<UnitOfWork>(
new ContainerControlledLifetimeManager());
However, I'm noticing that my context is not recreated with every new web request which is what I think I would want (let me know if I'm wrong in that assumption). I'm having a hard time analyzing all of the information from the sites listed below and have read about a lot of people creating their own class named PerHttpRequestLifetimeManager to handle this.
What truly is the best practice here?
Understanding Lifetime Managers by Microsoft's Developer Network - http://msdn.microsoft.com/en-us/library/ff660872(v=PandP.20).aspx
MVC DI & Unity with Lifetime Manager via CodeProject - http://www.codeproject.com/Articles/424743/MVC-DI-Unity-with-Lifetime-Manager
ASP.NET MVC Tip: Dependency Injection with Unity Application Block via Shiju Varghese's Blog - http://weblogs.asp.net/shijuvarghese/archive/2008/10/24/asp-net-mvc-tip-dependency-injection-with-unity-application-block.aspx
MVC, EF - DataContext singleton instance Per-Web-Request in Unity via Stack Overflow - MVC, EF - DataContext singleton instance Per-Web-Request in Unity
Inject same DataContext instance across several types with Unity via Stack Overflow - Inject same DataContext instance across several types with Unity
Yes, you usually want one DbContext per request.
A PerHttpRequestLifetimeManager or child container created on every request are the typical ways this is handled.
The latest release of Unity introduces the Unity bootstrapper for ASP.NET MVC which has a new built-in lifetime manager: PerRequestLifetimeManager.
You can read more in the Developer's Guide to Dependency Injection Using Unity chapter 3, Dependency Injection with Unity.
I am working on creating a SOA project. I want to use Jersey to expose the services on rest. In my project the standard is to create a API project which has API interfaces and DTOs. The implementation project depends on the API project and all implementation is written in the implementation.
The idea behind this architecture is that, we could create two API projects one for REST and other for SOAP, annotate the interfaces with required annotations. As a result the implementation would be unaware about the method used to expose the service (I mean REST and SOAP).
But the problem in Jersey is unable to discover the annotations on the interface and keeps throwing following exception
com.sun.jersey.api.container.ContainerException: The ResourceConfig instance does not contain any root resource classes.
A similar question has already been asked - JAX-RS Jersey/Grizzly Define an interface resource - The answer says that it is possible using Spring-Jersey.
But I tried various configuration options for spring-jersey - including - http://jersey.java.net/nonav/apidocs/1.8/contribs/jersey-spring/com/sun/jersey/spi/spring/container/servlet/package-summary.html
But did not have any success.
Questions
The idea of trying to manage the different ways of exposing service thru interface, is it a feasible and good idea? How are experts in the industry doing?
How can I manage to use Jersey to understand the annotations done on Interface?
Is some other framework like RestEasy going to help?
I'm trying to design the architecture for a new LOB MVVM project utilising Caliburn Micro and nHibernate and am now at the point of looking into DI and IOC.
A lot of the examples for bootstrapping Caliburn Micro use MEF as the DI\IOC mechanism.
What I'm struggling with is that MEF seems to by reasonably popular but the idea of the Mef [Imports] annotations smells to me like another flavour of a Service Locator?
Am I missing something about MEF whereby almost all the examples I've seen are not using it correctly or have I completely not understood something about how it's used whereby it side steps the whole service locator issues?
MEF is not a Service Locator, on it's own. It can be used to implement a Service Locator (CompositionInitializer in the Silverlight version is effectively a Service Locator built into MEF), but it can also do dependency injection directly.
While the attributes may "smell" to you, they alone don't cause this to be a service locator, as you can use [ImportingConstructor] to inject data at creation time.
Note that the attributes are actually not the only way to use MEF - it can also work via direct registration or convention based registration instead (which is supported in the CodePlex drops and .NET 4.5).
I suppose if you were to just new up parts that had property imports and try to use them, then you could run into some of the same problems described here: Service Locator is an Anti-Pattern
But in practice you get your parts from the container, and if you use [Import] without the additional allowDefault property, then the part is required and the container will blow up on you if you ask for the part doing the import. It will blow up at runtime, yes, but unlike a run of the mill service-locator, its fairly straightforward to do static analysis of your MEF container using a test framework. I've written about it a couple times here and here.
It hasn't been a problem for me in practice, for a couple of reasons:
I get my parts from the container.
I use composition tests.
I'm writing applications, not framework code.
This relates to DI as much as it relates to the Zend framework. My question is about where to use the DI container. Should it only every be used durring bootstrap for initialization leaving the rest of the application ignorant of existence? Or is it good practice to pass it to controllers, models, helpers, etc to be used there if needed? What about Zend 2?
As it relates to dependency injection in general, that is something you should be practicing if you are attempting to write SOLID code. I have two articles I've written on the subject of Dependency Injection as it relates to the background knowledge (I think) developers should have before jumping directly into code that uses a DiC:
http://ralphschindler.com/2011/05/18/learning-about-dependency-injection-and-php
I've also compiled some examples of how to use Zend\Di that is a DiC component in the ZF2 codebase:
https://github.com/ralphschindler/Zend_DI-Examples/
Another point, I'd like to make ... Once you start passing the DiC as a dependency into controllers, models etc ... your DiC actually becomes a Service Locator at that point. This is perfectly acceptable, but you need to be aware up front that using a Service Locator would/should have been part of your design goals.
The next beta cycle of ZF2 will probably better address how Di and Service Locators are used through modules, controllers and how dependencies are pushed into things like helpers and models. So keep an eye out for that.
Hope that gets you started.
I have been reading some of the answers. First, as far as I know, it is currently not built in with the Zend framework < ver 2 to have the Dependency Injection Container do its work in the "composition root".
Hence, your best bet would be a service locator as mentioned already here. I have come up with a Zend framework application setup to do just that. Check it out over here.
In a nutshell, what it does is
Bootstrap Symfony Dependency Injection in the Zend Application Bootstrap class
Get the container from 1 in a Zend controller where you can use it to retrieve your services
I'm a Gwt beginner. My remote service implementation now uses a DAO.
For the sake of example, I'm creating it myself:
StocksDAO myDao = new StocksDAO();
Now I was thinking to add Spring IOC for injecting it.
Then I came across this GUICE framework... it can be interesting but...
How to quick start? Is there a simple tutorial over the web suitable to my simplicity example?
GWT remote service is implemented as a Servlet. To use Guice with Servlets, look at the docs: http://code.google.com/p/google-guice/wiki/Servlets
Also, this has been discussed earlier: GWT Guice/Gin on the server side problem
Have a look at the sample application which will demonstrate use of Guice with GWT specifically with Request Factory.
http://code.google.com/p/guice-gwt/