I want to use Unity interception for an interface without an implementation, so that the IInterceptionBehavior actually becomes the implementation. This is the same as the CreateInterfaceProxyWithoutTarget method in Castle Dynamic Proxy.
Is this possible in Unity?
I think no, the only way I know to intercept an interface is with an InterfaceInterceptor but it requires a base class to be registered in the container:
Container.RegisterType<IRepository, BaseRepository>(
"repo1",
new Interceptor(new InterfaceInterceptor()),
new InterceptionBehavior(new RepoLoggingBehavior())
);
It's been a long while since this question was posted, but I came across it while trying to figure out just the same, and well, it seems like I've come up with something.
I've made it work by using Intercept.NewInstanceWithAdditionalInterfaces.
In my sample below I want a Unity to create an instance of a non defined class implementing IUserDao. All I want that instance of that Unity created class to do is defined in RetrieveSavedResultBehavior.
IUserDao userDao = (IUserDao)(Intercept.NewInstanceWithAdditionalInterfaces<Object>(
new VirtualMethodInterceptor(),
new List<IInterceptionBehavior>(){new RetrieveSavedResultBehavior()},
new List<Type>() { typeof(IUserDao) }
));
You can check my post regarding this topic here
Related
Autofac provides the OnActivated() method, which provides the capability to run any action after constructing a registered type.
Is possible to use a similar method in MvvmCross? Do you have any ideas to provide the same functionality?
It usually pays to understand the fundamentals of Dependency Injection (DI) instead of relying on particular DI Container features. Ask yourself the question: If I didn't have a DI Container, then how would I solve my problem?
Ironically, it turns out that things are usually much simpler with Pure DI.
If you didn't have a DI Container, then how would you run an action after construction of an object?
The easiest solution is to provide a factory that creates and initialises the object. Assuming the same API and requirements as the Autofac documentation implies, you could do this:
public static Dependency2 CreateDependency2(ITestOutputHelper output, Dependency1 dependency)
{
var d2 = new Dependency2(ITestOutputHelper output, Dependency1 dependency);
d2.Initialize();
return d2;
}
If you still must use another DI Container, most of them enable you to register a factory like the above against the type. I don't know how MvvmCross works, but I'd be surprised if this wasn't possible. If it isn't, you can implement an Adapter over your actual dependency. The Adapter would take care of running the action on the adapted object.
FWIW, if an object isn't in a valid state before you've run some action on it, then encapsulation is broken. The fundamental characteristic of encapsulation is that objects protect their invariants so that they can never be in invalid states. If possible, consider a better API design.
I've registered a type in Caliburn Micro using it's Simple Container as a singleton.
_container.Singleton<MyType>("MyType");
Now I've realized I need to pass in some specific constructor parameters, so I created an instance of the registered class, configured it, then tried to use RegisterSingleton. And realized it doesn't seem to let me pass a specific instance. I've looked at the docs and don't quite understand how this was supposed to work.
How can I get it to use this specific instance for the singleton?
Call SimpleContainer.RegisterInstance with the service type, key and implementation.
For example:
_container.RegisterInstance(typeof(MyType), "MyType", new MyType());
The simple container is documented here.
Still exploring the new ASP.NET MVC5, now with build in DI!
No Problem so far, I can just inject my Handlers (I don't like the Term Service, since this defines to me a Platform-Neutral Interface):
// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
services.AddApplicationInsightsTelemetry(Configuration);
services.Configure<Model.Meta.AppSettings>(Configuration.GetSection("AppSettings"));
services.AddSingleton(typeof(Logic.UserEndPointConfigurationHandler));
services.AddSingleton(typeof(Logic.NetworkHandler));
services.AddMvc();
}
Works fine, also the strongly typed Configuration-Object "AppSettings" works perfectly fine.
Also the Injection in the Controllers works as well.
But now my collaps: I seperated my DataAccess from the Handlers, and obviously I'd like to inject them as well:
public class UserEndPointConfigurationHandler
{
private readonly DataAccess.UserEndPointAccess _access;
public UserEndPointConfigurationHandler(DataAccess.UserEndPointAccess access)
{
_access = access;
}
But bam, UserEndPointAccess can't be resolved. So it seems like even I directly request to DI an Class with a Parameterless-Constructor, I need to register that. For this case, sure I should Interface and register them, but what does that mean for internal helper classes I also inject?
According to the Docs: http://docs.asp.net/en/latest/fundamentals/dependency-injection.html#recommendations and also the examples I found, all people in the world only seem to communicate between Controllers and some Repositories. No Business-Layer and no Classes on different Abstraction-Levels in Assemblies.
Is the Microsoft DI approach something totally differnt than the good ol' Unity one, where I can really decouple as fine granular as I'd like to?
Thanks in advance.
Matthias
Edit #Nightowl: I add my answer here, since it's a bit longer.
First of all, Unity does automatically create Instances, if I request a conecrete Type. This allows me to inject Types I register and Types, like Helper classes etc. I don't need to. This combination allows me to use DI everywhere.
Also in your Example I'd need to know the DataAcces in the WebGui, which is quite thight coupled. Well, I know there are solutions for this via Reflection, but I hoped Microsoft did something in this Topic, but probably that'd mean to big of a change.
Also allows Unity to store Instances or Instructions how to create them, another huge feature, which is missing at the moment.
Probably I'm just to spoiled, what refined DI-Libraries do, probably they also do to much, but at the moment the Microsoft-Implementation is just a huge downgrade according to my Information.
MVC Core follows the the composition root pattern, which is where object graphs are created based off of a set of instructions to instantiate them. I think you are misinterpreting what the IServiceCollection is for. It does not store instances, it stores instructions on how to create instances. The instances aren't actually created until a constructor somewhere in the object graph requests one as a constructor parameter.
So, in short the reason why your service (which you call UserEndPointAccess) is not being instantiated when you request it is because you have not configured the IServiceCollection with instructions on how to create it.
// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
services.AddApplicationInsightsTelemetry(Configuration);
services.Configure<Model.Meta.AppSettings>(Configuration.GetSection("AppSettings"));
services.AddSingleton(typeof(Logic.UserEndPointConfigurationHandler));
services.AddSingleton(typeof(Logic.NetworkHandler));
// Need a way to instantiate UserEndPointAccess via DI.
services.AddSingleton(typeof(DataAccess.UserEndPointAccess));
services.AddMvc();
}
So it seems like even I directly request to DI an Class with a Parameterless-Constructor, I need to register that.
If you are doing DI correctly, each service class will only have a single constructor. If you have more than one it is known as the bastard injection anti-pattern, which essentially means you are tightly coupling your class definition to other classes by adding references to them as foreign defaults.
And yes, you need to register every type you require (that is not part of MVC's default registration). It is like that in Unity as well.
There is the example of creating and using a service in the official documentation. At start we create some class, then register it in config/services.yml an then we can use it in our code like this:
$result = $this->get('app.myservice')->myMethod($arg);
//(In the [example][1] it is little bit other code:)
//$slug = $this->get('app.slugger')->slugify($post->getTitle());
But WHAT FOR? while I can just do the SAME like this:
use MyServiceNamespace/MyService
//...
$result = (new MyService())->myMethod($arg);
Where is profit of using Services? Is this just syntax sugar?
Nope. Far from syntax sugar.
You need to have a working understanding of what dependency injection means. Perhaps start by skimming through here: http://symfony.com/doc/current/book/service_container.html
Let's suppose your service needs a doctrine repository to do it's job. Which is better?
class MyController
{...
$userManager = $this->get('user.manager');
OR
$userRepository = $this->getDoctrine()->getManager()->getRepository('MyBundle::User');
$userManager = new UserManager($userRepository);
Your choice but once you have worked through the mechanics of how to add a service then you will never look back.
I should also point out that your sluglfy example requires a use statement and ties you code directly to a specific implementation. If you ever need to adjust your slugification then you need to go back and change all the places where it is used.
// These lines make your code more difficult to maintain
use Something\Slugify;
$slugify = new Slugify();
AS Opposed to
$slugify = $this->get('slugify');
'tIn this case, it's not really relevant. But from a simple design concern, services allow to make a better dependency management.
For instance, if you declare a service relaying on another one, then you won't have to instanciate both of them. Symfony will take care of it.
And since your declaration is centralized, any modification on the way you decide to create your service (= declare it), you won't have to change all the references to the services you changed since symfony will take care of the way it's instanciated when needed.
Another point is the scope of services. This information might be checked, but I think symfony instanciate service once (Singleton) which mean a better memory usage.
I've got a class called ArtificialIntelligenceBase from which you can create your own artificial intelligence configuration sending some variables to the constructor or you can make a class that inherits from ArtificialIntelligenceBase and in the constructor of this new class just call the function super() with the parameters of the configurations.
I've also created some examples of artificial intelligences in classes, AIPassive, AIAgressive and AIDefensive. Obviously all of them inherits from ArtificialIntelligenceBase.
The point is that there're only few public functions in the base class. The variables in the base class are read only and the non public functions are protected in case you need to apply some modifications on them when created another pre-defined AI.
You can also create another AI just calling the base class sending some parameters in the constructor like this: new ArtificialIntelligenceBase(param1, param2, param3, param4);
I've tought about make the classes as a singleton because the classes can never change and once setted, their variables never change.
The question is: Is the singleton the best pattern to do this? Because I'm not sure.
PD: You don't need to explain any patter, just mention the name and I'll search for how it works
PPD: I'm developing in AS3. Just in case it helps
Thanks
In general, singletons are evil. I don't see any reason in your case to use a singleton, either. It sounds like you're using your own version of a factory method pattern (using a constructor somehow?) or maybe a prototype (I don't know AS3 one bit), but if you're looking for other patterns a couple of other ones are abstract factory and builder.
You don't need to use the singleton pattern to limit yourself to using only one instance per type of class, though. It doesn't help avoid redundancy.