Is it possible to inject a request scoped CDI component into a application scoped CDI component via construction injection? The point is that, when the application scoped object is instantiated, the request scoped object might not exist.
You're free to do this, you get a proxy injected that obtains/creates the appropriate instance when you call a business method on it.
Related
I have interface (e.g. IMyInterface). I need to get of which type object will be created if I call kernel.Get<IMyInterface>(). Not the instance of IMyInterface but the type of instance without creating instance itself. Is it possible?
Ninject doesn't have this functionality. From a Ninject IKernel (like StandardKernel) you can call GetBindings(Type) but Ninject uses a provider model, so the binding's provider has to be invoked to view the result.
I would suggest creating a custom meta-service to mappings of services to implementations, if this functionality really needs to be dynamic.
I would like to know in best practice questions and think of easily testable classes, when I need multiple different instances of the same (fabricated) object within a specific class, which approach is recommended?
Before I used the Service Manager build method, but it is no longer recommended to inject Service Manager directly into a class, right?
Every once in a while, I'm encountering the following exception in my ASP.NET/MVC5/WebAPI2/EF6/MSSQL application:
System.InvalidOperationException: The context cannot be used while the model is being created. This exception may be thrown if the context is used inside the OnModelCreating method or if the same context instance is accessed by multiple threads concurrently. Note that instance members of DbContext and related classes are not guaranteed to be thread safe.
I've traced this to my authorization code, which is a derivative of AuthorizeAttribute and instantiating its own DbContext to verify that my Web API consumer's API key is valid (the error occurs when trying to access the database).
The AuthorizeAttribute in turn decorates controllers which are derivatives of my BaseController, which also instantiates a DbContext for controller work.
After trying to troubleshoot this for days and reading this and this I suspect that creating the two DbContext instances per request is the problem. However, I'm not quite sure how I can use only a single instance for this work. My controller code currently nicely instantiates the DbContext upon its own creation and disposes of it transparently when the controller itself disposes. The AuthorizeAttribute is completely independent from all this and creates the context on demand for its own purposes.
Any patterns/ideas how to preserve/reuse the same DbContext for both units of work?
I had exactly the same issue when starting out with a base application using Entity Framework 6 for the first time.
The best solution for me was to ensure only one DbContext instance during the request life cycle using Autofac (with MVC integration) and Autofac's InstancePerRequest lifetime scope.
If you're interested in going down the dependency injection route (which I'd strongly advise) I would recommend familiarizing yourself with Autofac - and for more information on your particular issue check out davidbitton's answer here - it will get you on the right track.
I have an EJB that needs to be a singleton and stateful since it's going to be a sort of connection pool. My questions are:
If I define an EJB with #Singleton annotation, will it then be stateful by default or do I have to define it with #Stateful also?
Can it be annotated with #Stateless?
Tried to find some documentation about this but no luck so far. So anyone with knowledge, please share your wisdom and perhaps a link or two.
The EJB tutorials show that an EJB can be either Singleton or Stateful or Stateless. I have never tried to use more than one of these annotations, but I am fairly convinced that the right thing to do is to use only one of them.
From that link:
Singleton session beans maintain their state between client
invocations
So, to your question:
if I define a EJB with #Singleton annotation will it then be stateful by default or do I have to define it with #Stateful also?
If for Stateful you mean the ability to maintain its state, the answer is: yes, a Singleton will be Stateful by default.
Keep in mind that there are some particular situations in which a Singleton doesn't behave like a Singleton, read this article about this. Generally, you don't run this kind of risk if you are outside of a cluster and avoid using the default constructor: you need to always use references of an EJB by injecting it in another EJB or a web client using:
#EJB MyEJB myEJB;
Finally, have a look at this part of the Java EE 6 tutorial, about EJBs lifecycle, explaining that the main difference between Stateful and other EJBs is the ability to being passivated by the container during its life. This difference is the main reason why the statement "a Singleton is Stateful by default" is not correct strictly speaking, but is correct in the context of your question.
I've read a couple of articles about creating a generic repository in Entity Framework. In every article the ObjectContext is passed as an argument to the constructor like this:
public Repository(ObjectContext context)
{
_context = context;
}
In a web application the preferred way to handle ObjectContext lifestyle is per web request. This means that these repositories must also have lifestyle per web request, if used in in a web context. This spreads to services using repositories and further on if we stick to constructor injection...
I think the ObjectContext life cycle should be handled outside the repositories, for example in a HttpModule. I would also like to handle repositories as singletons instead, and then ObjectContext can't be injected in the constructor. Another mechanism for getting the ObjectContext into the repository must be used, like an ObjectContextFactory.
Whats the downside of handling the repositories with a singleton lifestyle?
One issue with repositories being singletons, as with any other objects, is that determining what dependencies the repository has becomes more difficult. When you require that a context is passed in the constructor that is a clear declaration of a dependency on the ObjectContext class. If you were to use a static factory to get a reference to an object context then it would be necessary to see the implementation of the repository to know how it uses the factory.
A common way to achieve what you're looking for, namely the ability to manage the scope of the ObjectContext class outside of the repository is by using a dependency injection library, such as Autofac. You can register the ObjectContext class such that a new instance is created for every HTTP request. Then if you also register the repository class, when a repository is requested the dependency injection container will attempt to get a reference to the ObjectContext dependency. Since only one instance of ObjectContext will be created per HTTP request multiple repositories within that scope will receive the same instance. The Autofac page has example of integrating with ASP.NET that you can look at.