I'm currently developing a web application which uses MVC3. the MVC3 project accesses our Application logic through a Service layer. The Service layer accesses the Database using repositories accessed via the UnitOfWork pattern.
I just installed StructureMap to take care of injecting my Services into the MVC3 project. An Example controller would look like this
public class AccountManagementController : Controller
{
IAccountService accountService;
public AccountManagementController(IAccountService accountService)
{
this.accountService = accountService;
}
Now, my problem is that my AccountService class needs to have the UnitOfWork injected when structure map creates it. Currently I handle this by having 2 controllers. One takes an interface, the other instantiates a concrete class.
public class AccountService : IAccountService, IDisposable
{
private IUnitOfWork unitOfWork;
internal AccountService(IUnitOfWork unitOfWork)
{
this.unitOfWork = unitOfWork;
}
public AccountService()
{
this.unitOfWork = new UnitOfWork();
}
This seems like code smell to me. Is there a more correct way to handle this?
Thanks,
AFrieze
As Mark suggested I would delete the default constructor, but...
AFAIK, StructureMap choses always the constructor with the most arguments so this should not be an issue while resolving IUnitOfWork dependency.
On the other hand, IDisposable seems to me like a smell. AFAIK structureMap advice how to deal with disposable instances like that :
we should wrap the disposable service into the non disposable
wrapper. the non disposable wrapper should dispose the instance it
wrapps.
we should inject the factory of disposable service to the non disposable wrapper.
In these two cases we inject to the consumers the wrapper insteed of directly injecting the disposable service.
For structureMap we could also take advantage of the nested containers features, which tracks the disposable instances. So when the nested container is disposed, all object graph is released.
I don't smell anything as long as, like comments suggest, you remove the default parameterless constructor from AccountService. Any decent IoC container should be able to cascade the dependencies, so that when you inject IAccountService into AccountManagementController, it will resolve AccountService's dependency on IUnitOfWork
Related
In a Prism Xamarin app with DryIoc as container, I have a Unit of Work which is referenced by several other components which are then referenced from view models. It looks something like this (interface declarations skipped for briefness):
public class UnitOfWork : IUnitOfWork {...}
public class Service1 : IService1 {
public Service1 (IUnitOfWork unitOfWork) {...}
}
public class Service2 : IService2 {
public Service2 (IUnitOfWork unitOfWork) {...}
}
public class MyViewModel {
public MyViewModel (IService1 service1, IService2 service2) {...}
}
I have registered Service1, Service2 and UnitOfWork as transient, which means that when MyViewModel is instantiated, two instances of UnitOfWork are created, one for the reference in Service1 and one for the reference in Service2. I want to have the same instance of UnitOfWork to be used for both Service1 and Service2. However, I do not want to use a singleton but instead I am looking for a scoped instantiation, with the scope being equal to the creation of the corresponding view model.
DryIoc supports scopes but I cannot find any information about using scopes in Prism. I found a site describing Prism containers and DryIoc in particular but its page about scoping is empty.
I am looking for documentation or samples how to introduce and manage scopes in Prism. Any help in these regards is appreciated.
UPDATE:
I figured out that Prism/DryIoc creates a scope for each View/ViewModel that is opened, so if the services are registered as Scoped, they will also be resolved per View/ViewModel. However, I cannot find any way to configure these scopes, assign names, etc. and also I cannot find any documentation about this.
You can always, as a fallback if you like, manually create a factory for your services. Inject that into your view model together with the unit of work, and pass the unit of work to the factory when you use it to create the services.
Although it may look clunkier, I'd actually prefer that over some container-specific magic, because it's very straight forward to understand and not fragile at all.
There is an example what I want to do.
The service client is a Spring bean, which is retrieving from external configuration class and should be called from Spock extension.
class ServiceCleintExtension implements IGlobalExtension {
#Autowired
ServiceCLient client
#Override
void start() {
client.execute()
}
...
}
UPD:
I've found a solution by using Spring TestExecutionListener and custom static "container" for SpecInfo/FeatureInfo.
No that is not possible, IGlobalExtension are initialized and manged by Spock. Furthermore, they are singletons which doesn't mesh well with multiple possible Spring contexts.
If you just want to call a method on an injected bean during setup, then I'd suggest to use an annotation based extension. Look at the builtin AutoCleanup extension for reference.
As part of the Spring MVC initialization, I need to run an action (just calling a method on a 3rd party library) once as a setup operation. I'm working in Spring MVC environment where I don't really have control over the web.xml or anything, so I can't add a servlet context listener or anything. I tried making an implementation of a WebApplicationInitializer but it never seems to get called (no idea why though, or how to try and debug that any further).
If I annotate a class with #Configuration it does get created, so I'm wondering if I can use the class's constructor to perform that setup operation (calling a 3rd party setup method). Is this appropriate/safe to do? Are there any other alternatives for this kind of thing? I'm new to Spring, so I might just be missing something that's meant for this kind of thing.
Thanks
Configuration class would be an appropriate place to contain some initialization logic. You can place it in a constructor, method annotated with #PostConstruct or afterPropertiesSet() method if you implement the InitializingBean interface for example. The difference is that the constructor code will be called before the beans in your configuration class are instantiated, so if your initialization code depends on some Spring beans, go with the #PostConstruct / InitializingBean approach.
Example:
#Configuration
public class Config {
#PostConstruct
public void initialize() {
// Run some action
}
}
I have this problem...
I have a VS solution with these projects: Persistance, Domain, Services, UI.
Now my problem is that I must reference nhibernate in all project that uses something of nhibernate.
Is it possible that I reference nhibernate only in Persistence project and that any project that have reference to Persistence project can use nhibernate too?
I am using StructureMap as DI container. And I have setup dependency injection through constructor for ISession. So I must reference nhibernate in every layer (not UI) that passes ISession.
What I want is not have nhibernate.dll and all its dependency dll (bytecode.linfu...) referenced in nearly all my projects, but only in persistence. Is this somehow possible?
Thanks
In your Domain projects, you define the interfaces for your data acces objects. Your NHibernate persistence project can reference the Domain project and provide implementation for the data access objects.
Your service project might reference Domain and not Persistence. Your service objects depend on the data access interfaces in Domain. You use your DI container to wire your service objects to the NHibernate implementations in Persistence.
Changing the dependency Domain -> Persistence to Persistence -> Domain is an example of inversion of control.
I can imagine you now have the following service:
using Persistence;
using Domain;
public class UserService
{
private Persistence.NHibernateUserRepository _repository;
public UserService (ISession session)
{
_repository = new Persistence.NHibernateUserRepository(session);
// ...
}
// some service methods
}
I suggest to change this to:
using Domain; // no longer using Persistence package
public class UserService
{
private Domain.IUserRepository _repository;
public UserService (Domain.IUserRepository repo)
{
_repository = repo;
// ...
}
// some service methods
}
In your StructureMap configuration, you configure an NHibernate Session, which you wire to your Persistence.NHibernateUserRepository. Then you wire your UserService to this Persistence.NHibernateUserRepository. I'm not familiar with StructureMap, so I can't help you with the mechanics. You might want to read:
Injecting ISession Into My Repositories Using Structuremap in a Asp.Net MVC Application
http://www.bengtbe.com/blog/post/2009/02/27/Using-StructureMap-with-the-ASPNET-MVC-framework.aspx - this is a post that discusses exactly your problem, including StructureMap, NHibernate and asp.net mvc.
I would like to know if it's possible to use Spring to resolve the dependencies of an object created manually in my program. Take a look at the following class:
public class TestClass {
private MyDependency md;
public TestClass() {
}
...
public void methodThaUsesMyDependency() {
...
md.someMethod();
...
}
}
This TestClass is not a spring bean, but needs MyDependency, that is a spring bean. Is there some way I can inject this dependency through Spring, even if I instantiate TestClass with a new operator inside my code?
Thanks
Edit: The method I'm describing in my original answer below is the general way to accomplish DI external of the container. For your specific need - testing - I agree with DJ's answer. It's much more appropriate to use Spring's test support, for example:
#Test
#ContextConfiguration(locations = { "classpath*:**/applicationContext.xml" })
public class MyTest extends AbstractTestNGSpringContextTests {
#Resource
private MyDependency md;
#Test
public void myTest() {
...
While the above example is a TestNG test, there is also Junit support explained in 8.3.7.2. Context management and caching.
General approach: Annotate your class with #Configurable and utilize AspectJ load-time or compile-time weaving. See 6.8.1 in the Spring documentation on AOP for more details.
You can then annotate your instance variables with #Resource or #Autowired. Though they accomplish the same goal of dependency injection, I recommend using #Resource since it's a Java standard rather than Spring-specific.
Lastly, remember to consider using the transient keyword (or #Transient for JPA) if you plan on serializing or persisting the objects in the future. Chances are you don't want to serialize references to your DI'd repository, service, or component beans.
See the autowire() method on the AutowireCapableBeanFactory class. If you use an ClasspathXmlApplicationContext, you can get the factory with getAutowireCapableBeanFactory()
To get the ApplicationContext, you would need to use a static singleton or other central repository, such as JNDI or a Servlet container. See DefaultLocatorFactory on how to get an instance of the ApplicationContext.
If what you need is for testing purposes, Spring has good support for the scenario that you described above.
Check out Spring Reference manual section on Testing