Resolve with parameter

Apr 18, 2011 at 4:37 PM

Hi,

Does munq have the feature to resolve type with concrete parameters? For example, container.Reolve(...).WithParameter(parName, parValue).

Alexandr.

Coordinator
Apr 19, 2011 at 4:17 PM

Unfortunately not.  However, you might look at Funq, which does have this feature.

 

Matthew

Apr 19, 2011 at 6:48 PM
Edited Apr 19, 2011 at 6:48 PM

When i was choosing a DI your IoC was the best. As i know Funq is good at silverlight application but i have asp.net mvc3. I looked at discussions of Funq and it is dead but your project is developing. So I start using your DI in my project and it would be a little difficult to change it. On this stage, I need such feature. Can you implement it or it is very difficult? Please give response in short time b/c i am very hurry.
Thanks A lot,
Alexandr.

Coordinator
Apr 19, 2011 at 9:50 PM
Could you give me an example of what you are trying to do? It may be that doing things in a slightly different way will accomplish what you need.
Possibly, move the logic that uses the parameter into a method on the class, and call it after the instance is resolved.

Matthew

From: TRiV
Sent: Tuesday, April 19, 2011 1:48 PM
To: matthew.dennis@sympatico.ca
Subject: Re: Resolve with parameter [Munq:254361]

From: TRiV

When i was choosing a DI your IoC was the best. As i know Funq is good at silverlight application but i have asp.net mvc3. I looked at discussions of Funq and it is dead but your project is developing. So I start using your DI in my project and it would be a little difficult to change it. On this stage, I need such feature. Can you implement it or it is very difficult? Please give response in short time b/c i am very hurry.
Thanks A lot,
Alexandr

Apr 21, 2011 at 2:33 PM
Edited Apr 21, 2011 at 2:35 PM

I have IDataManager interface and MSSqlDataManager class. The constructor of MSSqlDataManager take connection string parameter.

So i need to do:

container.Resolve(IDataManager).WithParameter("connectionString", ConfigurationManager.ConnectionStrings["MSSqlConn"].ConnectionString).

I use this construction quite often, and move this logic on other class will be incomprehensible for other developers.

Best regards,

Alexandr.

Coordinator
Apr 21, 2011 at 3:20 PM
Edited Apr 21, 2011 at 3:23 PM

You can accomplish this by

container.Register<IDataManager>(c => new MSSqlDataManager(ConfigurationManager.ConnectionStrings["MSSqlConn"].ConnectionString));

Then when you resolve

IDataManager dataManager = container.Resolve<IDataManager>();

the code to get the configuration string will be automatically executed.

If you need more than one connection string then

// Create named Registrations for IDataManager

container.Register<IDataManager>("Conn1", c => new MSSqlDataManager(ConfigurationManager.ConnectionStrings["Conn1"].ConnectionString));

container.Register<IDataManager>("Conn2", c => new MSSqlDataManager(ConfigurationManager.ConnectionStrings["Conn2"].ConnectionString));

container.Register<IDataManager>("Conn3", c => new MSSqlDataManager(ConfigurationManager.ConnectionStrings["Conn3"].ConnectionString));

Then to get a specific IDataManager

IDataManager dataManager = container.Resolve<IDataManager>("Conn2")'  // Get the connection named "Conn2"

Some further notes.

Now, the users don't need to know about the connection string at all.

If you need to change how the connection string is retrieved, only the registration code needs to change.

Matthew

Apr 21, 2011 at 7:08 PM

Your solution works but not in my scenario.

I need to set half of parameters by myself and another part must be resolver automatically.

MSSqlDataManager in constructor also has ILogManager, thats need to be resolver automatically.

Thanks,

Alexandr.

Coordinator
Apr 21, 2011 at 8:46 PM

Then register like:

container.Register<IDataManager>("Conn1", c => new MSSqlDataManager(ConfigurationManager.ConnectionStrings["Conn1"].ConnectionString), c.Resolve<ILogManager>());

 

Matthew

Apr 21, 2011 at 9:26 PM
Edited Apr 21, 2011 at 9:28 PM

But if other developer changed MSSqlDataManager, and add third parameter, he will have understand, where and how change the code of registration, to make it working.

Approach "WithParameter" relieves developer from it problem.

Best regards,

Alexandr.

Coordinator
Apr 21, 2011 at 9:50 PM
Edited Apr 21, 2011 at 9:53 PM

Then create an ISqlConnectionString interface

public ISqlConnectionString{
    string ConnectionString { get; }
}

create an implementation

public class MyConnetionString : ISqlConnectionString
{
    public string ConnectionString { get { return ConfigurationManager.ConnectionStrings["Conn1"].ConnectionString; }}
}

Then if the constructor is like

    public MSSqlManager(ISqlConnectionString connString, ILogManager logger) ...

and you register

    container.Register<ISqlConnectionString, MyConnectionString>();
    container.Register<ILogManager, MyLoggerImpl>();

now you can

MSSqlManager sqlManager = container.Resolve<MSSqlManager>();

Now, if you change the constructor for MSSqlManager, as long as you register the new interface dependencies, the above call does not have to change.

In other words, the users do not need to know any of the dependencies, the container will automatically resolve all the constructor parameters.

Matthew

Apr 22, 2011 at 3:30 PM

As I had said before, I use this construction quite often, and MSSqlManager is only simple example.

If i start creating interfaces and classes for solving this problem, there will be much more code and it will confuse other developers.

Whats about implementing this feature in Munq?

Thanks,

Alexandr.

Coordinator
Apr 23, 2011 at 10:03 PM

The source is available. Go for it.

Matthew

Jul 30, 2011 at 1:49 PM

Hi Matthew,

Is the WithParameter feature implemented in the latest version? I can only find WithLifeTimeManager in the IRegistration.

Am I missing something?

Thanks!

Jul 30, 2011 at 2:04 PM

Also, do you support property and method injection?

Thanks!