Project is dead?

Jan 23, 2011 at 2:03 PM

Hi all,

I am wondering will this project continue developed?

which application it was made for?Is it survive in production(I talk about web production)?

What can you say about similar project http://funq.codeplex.com/?Is it faster or better?

Feb 3, 2011 at 7:38 PM

My understanding is that munq is largely derived from funq but has some specific application to e.g. ASP.Net MVC. I'm using it currently in a WCF service. Funq targets Windows Mobile applications and has a build for Silverlight as well. I think Microsoft has now released funq as part of their Mobile Application Block. How this relates to Windows Phone 7 is beyond me but I have built funq/munq for desktop use.

Both funq and munq are exceptionally fast when compared to some of the more established DI frameworks but are also less feature rich. I like the no cruft approach and lambda-based syntax but I'm leaning towards StructureMap which I've heard good things about and is one of the more established containers. I was hoping munq might show up in nuget but Matthew appears to be focused elsewhere. I don't think the project is dead but we munq's are something of a secret society.

Feb 5, 2011 at 2:43 PM

HI

As i understand you was using munq. Can you tell me if it can be used in production?? Can it survive at a big load?

Thanks

Coordinator
Feb 6, 2011 at 10:36 PM

You are free to use Munq in any way you desire, including production.  Since it is so fast, it should fare better than some of the other IOC Containers.  However, please get the latest source, I just corrected a potential threading issue. (it wouldn't have prevented applications from working, but may have occassionally created instance instead of using a cached value).

Coordinator
Feb 6, 2011 at 10:47 PM

The projects are very similar in concept.  In fact, I got the idea for Munq when helping resolve some performance issues in Funq.  The two IOC containers target slightley different usage senarios, Funq targets mobile apps, where Munq has features specific to web development, but both can be used in most situations.

The latest source include automatic constructor resolving so that you can register without having to resolve each of the implementor's constructor parameters.  It finds the constructor with the most parameters and automagically resolves each type.  For example:

container = new Container().UsesDefaultLifetimeManagerOf(lifetime);
container.Register<IWebServiceWebService>();

container.Register<IAuthenticatorAuthenticator>();

container.Register<IStockQuoteStockQuote>();

container.Register<IDatabaseDatabase>();

container.Register<IErrorHandlerErrorHandler>();

container.Register<ILogger,Logger>().WithLifetimeManager(containerlifetime);
which will end up using the constructors (from the Perfomance Test Program)
WebService(IAuthenticator authenticator, IStockQuote quotes)
Authenticator(ILogger logger, IErrorHandler handler, IDatabase database)
StockQuote(ILogger logger, IErrorHandler handler, IDatabase database)
Database(ILogger logger, IErrorHandler handler)
ErrorHandler(ILogger logger)
Logger()



 

 

Feb 8, 2011 at 1:04 PM

Will the project continue developing or no???

Coordinator
Feb 8, 2011 at 2:02 PM

yes, i work on it when i can.  currently looking at a release for asp.net mvcE and nuget.

 

Feb 8, 2011 at 8:25 PM

Do you have an ETA on that?

Feb 9, 2011 at 8:34 PM
Edited Feb 9, 2011 at 10:49 PM

I was trying to use automatic constructor resolving. But i have problem with it it doesn't resolve constructor. look at code:

 


 

public static IIocContainer MainContainer;

MainContainer.Register<ITestClass, TestClass>().WithLifetimeManager(new ContainerLifetime());

 


 

    public class HomeController : Controller    {        //        // GET: /Home/
        ITestClass TestClass { get; set; }
        public HomeController(ITestClass testClass)        {            TestClass = testClass;        }        
        public ActionResult Index()        {
            return View(TestClass.Run());        }
    }

 


So it must work bit it does not. Can you give me advice of usage your ioc?

In castle windsor there is a method AddComponentWithLifestyle(fullname,type,lifestyle) with wich i can register component from it is type does munq have this feature??

 

 

Coordinator
Feb 10, 2011 at 1:49 AM
What version of ASP.NET MVC are you using. If Version 2 then you need to follow the instructions in http://www.codeproject.com/Articles/83416/Munq-IocContainer-V2-Overview.aspx, specifically the section titled Initializing the IOC Container.
Matthew
Feb 10, 2011 at 6:05 AM
Edited Feb 11, 2011 at 10:10 PM

I am using mvc 3. But even for Mvc2 that way is not possible for me. Because i will load controllers dynamically from assemblies(that located in defferent places). So i dont know how much parametres it will be in constructor. How can i register controllers not staticly like in your example but dynamically? Something like AddComponentWithLifestyle(fullname,type,lifestyle).

One more question if munq provides resolveall method or something similar? A you going to implement this feature?

I discover one big problem. So to auto resolve(i mean to create the object of some type and resolve in it's constructor the types that are in container) some type i need that to be in container but if i cant add it ?? Are you going to add this feature?? B/c without it i dont see the possibility of using your ioc.

Thanks

Coordinator
Feb 13, 2011 at 7:37 PM

Get the latest from the source tab.  I've been making some changes and improvements to add features and clean up the code.  It now will automatically resolve classes, without registration, using the constructor with the most parameters.

Thus, in MVC3, if I modify the AccountController to have a constructor

public AccountController(IMembershipService membershipSvc, IFormsAuthenticationService formsAuthSvc)
{
FormsService      = formsAuthSvc;
MembershipService = membershipSvc;
}
Then in the global.asx you need to do:

protected void Application_Start()
{
DependencyResolver.SetResolver(new MunqDependencyResolver());
var ioc = MunqDependencyResolver.Container;
ioc.Register<IMembershipServiceAccountMembershipService>();
ioc.Register<IFormsAuthenticationServiceFormsAuthenticationService>();
	// AccountMembershipService needs a MembershipProvider instance
ioc.RegisterInstance<MembershipProvider>(Membership.Provider);

AreaRegistration.RegisterAllAreas();
RegisterGlobalFilters(GlobalFilters.Filters);
RegisterRoutes(RouteTable.Routes);
}
 
Where MunqDependencyResolver is an implementation of the MVC IDependencyResolver and can be implemented as
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;

namespace Munq.Mvc3Samples
{
public class MunqDependencyResolver : System.Web.Mvc.IDependencyResolver
{
private readonly static Munq.Container _container = new Container();

public static Container Container { get { return _container; }}

public object GetService(Type serviceType)
{
try
{
return Container.Resolve(serviceType);
}
catch (KeyNotFoundException)
{
return null;
}
}

public IEnumerable<object> GetServices(Type serviceType)
{
return Container.ResolveAll(serviceType);
}
}
}

Feb 13, 2011 at 8:48 PM

Good timing, thanks Matthew. I'm two weeks from starting a new MVC3 project - nice to be able to continue to use Munq, much appreciated.