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.
Related
I noticed multiple ways in which developers create an Apache Felix Service. Each of the attached snippets seem to work. Would need some help to understand, which syntax is best for which scenario
Sample 1: Service created without interface
Declaration of Service
D
#Component
#Service(ServiceViaClass.class)
public class ServiceViaClass{
}
Using service via #Reference annotation
private ServiceViaClass serviceViaClass;
Sample 2:Service implementing interface. No value attribute for #Service annotation
- Declaration of Service
#Component
#Service
public class ServiceViaInterfaceImpl implements ServiceViaInterface{
}
Using service via #Reference annotation
private ServiceViaInterface serviceViaInterface;
Sample 3: Service implementing interface with value attribute for #Service annotation
- Declaration of Service
#Component
#Service(ServiceViaInterface.class)
public class ServiceViaInterfaceImpl implements ServiceViaInterface{
}
Using service via #Reference annotation
private ServiceViaInterface serviceViaInterface;
A component implements an interface and publishes itself as a service under that interface, so that clients can find the component using only the interface.
Sample 1 — publishing a service using the concrete type of the component — is nearly always useless. The service can only be found using the concrete type, and if clients can see the concrete type then why not just instantiate it directly rather than get an instance from the service registry??
Sample 2 — publishing a service by implementing an interface and then just adding the #Service annotation — is what you should usually do. When you use #Service and the component directly implements an interface, the build tooling infers that your component wants to be published as a service under that interface.
Sample 3 has the exact same effect at runtime as sample 2, it's just a bit more explicit in the code. Some people prefer this because it's explicit, others (including me) dislike it because it is redundant.
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 am trying to add some kind of tracing to my app. It would work like that: I set package name in my config and all calls to public methods of classes in this package are logged.
I can't use weaving here (due to some technical reasons), so I tried to use spring-proxy.
My pointcut
execution(public * com.my.package.*.*(..))
and it works fine. But what Spring uses Proxy or CGLIB to proxy class, so each class should at least
Have parameterless constructor
All methods should be implementations of some interface
Other classes could not be proxied. That is ok for me to do not log them. But spring creates proxies and ruins my app.
How can I tell spring: "do not proxy this class if it has no parameterless constructor and some of its methods are not implementations of interface"?
Not sure about the answer to your question, however, another way to do the tracing, is to use an annotation:
public #interface Monitor {
}
aspect:
public aspect MonitoringAspect {
pointcut methodToMonitor() : execution(#Monitor * *(..));
}
Usage:
#Monitor
public void methodToBeMonitored() {
}
This way you only affect the methods you want to.
I suppose for a big project, this might not work as you want to monitor many methods.
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
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.