I have the need to check if an instance of some interface has already been created by structuremap. I have tried ObjectFactory.GetInstance() but this creates a new instance of T when called and a concrete instance of T does not exist. I just want to check if an instance of T has already been created (not to create a new). I need this to force the creation of instances through a certain class).
You should be able to do this using:
ObjectFactory.Model.InstancesOf<IYourInterface>().First().ObjectHasBeenCreated();
Note, this only works for instances with Singleton, HttpContext or Hybrid lifecycle.
You cannot ask StructureMap if it has already created an instance of an interface.
However, it does have many lifecycle management features that allow it to control whether it creates a new instance, or returns a cached instance that it previously created.
You can tell StructureMap to make an instance HttpContextScoped, so that it returns the same instance for a given HTTP request.
It sounds like what you really want to know is how to handle NHibernate sessions in a web application with StructureMap. Try:
http://trason.net/journal/2009/10/7/bootstrapping-nhibernate-with-structuremap.html
Related
In Startup.cs it's possible to control dependency injection lifecycle using transients and singletons. However it's unclear how the lifecycle works when using .AddDBContext like so services.AddDbContext<DatabaseContext>(...);
Each controller uses this dependency by initialising it only once in the constructor and is reused throughout by the controller functions.
Is the context initialised for each request or is there a possibility this context being shared between user sessions resulting in bad state?
Note: duplicate question does not address if context is being shared between user sessions.
services.AddDbContext<>(...); registers your DbContext with Scoped lifetime. That means a new instance is created for every single request. No need to worry it would be shared with other connections.
I have a rest endpoint which would start the scheduler of loading a XML to memory. Whenever I hit that rest endpoint, it loads the XML in memory and would return the XML after its ready (would take 10 - 15 seconds). When the same endpoint is accessed again, it would return the cached XML. Everything works fine but for now I have to manually hit the endpoint for the scheduler to start. Is there a way to hit the endpoint automatically via a simple code in startup? Or is there any other solution for this?
Normally, a component in the Nucleus is instantiated at first access, not at system start-up.
The way to have anything done at start-up in ATG is to create your component, and then to add its nucleus path to the list of initial services in the /Initial component (or from one of the many other Initial components changed off of it)
The component should be globally scoped. Because /Initial is instantiated at start-up, the services it references will also be instantiated as dependencies.
If your component is a POJO, then the no argument constructor will be invoked on component start-up, then the setX method will be called for each property with a value defined in its properties file.
If your component is extended from Generic Service, then additionally, beforeSet and afterSet methods will be called, before and after the set methods are invoked, if they exist, and finally doStartUp will be called.
This is all part of the fundamental lifecycle of components that the Nucleus manages.
This gives you a number of hooks with which to invoke your custom code.
Now, in your question, you ask how to call a REST endpoint at start-up. However, I believe what you actually want to ask is how to ensure that a particular piece of code gets executed at system start-up. A REST endpoint is how you are triggering it today, manually, from outside the Nucleus. But that does not mean that it must call a REST end point if it is to be automatically called at start up.
The easiest way to achieve what you want is
define a class that extends GenericService
override the doStartUp method
put the code you want to execute in this method, or invoke the code on another component from here
define a globally scoped component for the class
Add the component to the initialServices property of the Initial component
Restart the server and check that your code is being called at start-up. Put some debug statements in, and switch debug logging on in your layer.
Note, you may actually also want to think about whether you really need to invoke your code at system start-up. Anything in initial services adds to the start time of the server. Depending on your requirements, it may be better to do it on first access of your application service rather than at server start-up.
I am very new to Autofac dependency injection and I got these questions related to my project. I have gone through many articles but I am not getting a clear picture on some of the questions I have. Mine is a service application on .Net REST API. I am doing instance registration in App_Start module as shown below.
private static IContainer RegisterServices(ContainerBuilder builder)
{
builder.RegisterApiControllers(Assembly.GetExecutingAssembly());
builder.RegisterType<DCLMessengerContext>()
.As<DbContext>()
.ExternallyOwned()
.InstancePerLifetimeScope();
builder.RegisterType<DbFactory>()
.As<IDbFactory>()
.ExternallyOwned()
.InstancePerLifetimeScope();
builder.RegisterType<UnitOfWork>()
.As<IUnitOfWork>()
.InstancePerLifetimeScope();
builder.RegisterGeneric(typeof(EntityBaseRepository<>))
.As(typeof(IEntityBaseRepository<>))
.InstancePerLifetimeScope();
builder.RegisterType<PersonServiceClient>()
.As<IPerfService>()
.InstancePerLifetimeScope();
builder.RegisterType<PagingServiceContractClient>()
.As<PagingServiceContract>()
.InstancePerLifetimeScope();
builder.RegisterType<MessageService>()
.As<IMessageService>()
.InstancePerLifetimeScope();
Container = builder.Build();
return Container;
}
My service layer is "MessageService" and there I am performing all the DB and other integration operations and getting the instances through constructor injection. These are the questions I have around this implementation.
I am using InstancePerLifeTimeScope for all my registrations. Is this is the right approach? After the life cycle of each controller request (http request), will these instances will be automatically disposed?
Do we need to manually implement any Dispose operation on any of these instances? ( I don’t have any unmanaged objects in my code)
From the service method, I need to create a fire&forget thread as well using Task.Run(). What is the best approach to supply instances to this fire&forget thread? If I use InstancePerLifeTimeScope, I can see that new thread also getting the same instances that available through the service class so I am just confused when these instances will be disposed?
When you resolve the instance per lifetime scope component, you get a
single instance per nested scope
So if you are using them in controllers. You will have one object for per request and they will be disposed. But if you resolve them in a singleton object they wil live with this object.
Is this is the right approach?
It depends what you need. If you need singleton object, it's not. If you just want to use this service in request scope use instanceperrequest it's better.
Autofac automatically calls dispose for IDisposable objects. If you
need dispose method, implement it. It's not related with autofac.
If you use another thread resolve objects in this thread. Otherwise when request disposed your objects will be disposed and your thread will be fail. Check this.
To be specific, I need to create an array variable that will be used for caching data, but I don't want to use ZF2 Cache Adapter.
I've tried to create a invokable class that would be used to instantiate object of my class that contains methods for setting and getting values from array that is also defined as a property of that class. As far as I understand, service manager treats all services as shared by default, which is supposed to create only one instance off my class when I get the service by service manager method get for the first time. But this doesn't work, if I get that service in different actions in my Controller class, which is what I need to do. So, how am I supposed to achieve this effect? Create an object that is available application-wide?
I had this kind of problem with managing a cart.
My cart is modeled by a CartManager, which is a unique instance for a user (session) and until paiement (cart is persisted in database).
I register my CartManager as a Service to build the first instance, this instance is built during an event handler attached on MvcEvent::EVENT_ROUTE, once built I override the CartManager service with my Instance, this way wherever I call the service, my first instance is served.
Then I persist (session or database) my Instance in an other event handler attached on MvcEvent::EVENT_FINISH.
All the event handlers are attached in Module::onBoostrap()
I'm building a plugin for a 3rd party application and my plugin uses Autofac to wire up various components. The container is built at application startup, but the host application invokes my commands at a later time.
When a command is invoked, the host application provides a few instances of types that it defines and that my components will need to use. I'd like to register these instances in the container so that it can take care of wiring up the components that depend on these instances.
I'm aware that I can use a ContainerBuilder to update an existing container, but I'd like to remove these registrations when the command has completed as these instances will no longer be valid. Is this possible?
Maybe a better approach is to use 2 containers... The command could create a new container to register these instances and other components could be resolved from the application scoped container.
How could I hook up the 2 containers so that resolve calls bubble up to the application scoped container?
Are there any gotchas to be aware of with this approach? I imagine there may be component lifetime issues...
Edit: Now I've done a bit more research and testing and and it turns out I can just use the BeginLifetimeScope(Action<ContainerBuilder>) overload to register the host application provided instances for the nested lifetime only. For some reason I thought that adding registrations to the nested lifetime would result in them being added to the root container but that doesn't seem to be the case.
As noted in my edit above, it turns out that BeginLifetimeScope(Action<ContainerBuilder>) is exactly what I need. For some reason I thought that adding registrations to the nested lifetime would result in them being added to the root container and therefore being resolvable after the nested lifetime scope ends, but that doesn't seem to be the case.