Question about how the CustomerController and other Nop Controllers work

I'm trying to use the CustomerController from within my own custom class. I have noticed that the CustomerController and most other Nop Controllers use an extensive parameter list in their Constructors.

When and where do these Constructor type of arguments get created and initialized?


* Related Note while stepping through code and debugging:

I have looked in the RouteProvider.cs file and looked at the following mapping and do not understand how it can work. Where does the parameters for the constructor get passed?

routes.MapLocalizedRoute("Register",
                            "register/",
                            new { controller = "Customer", action = "Register" },
                            new[] { "Nop.Web.Controllers" });

For visibilities sake here is the prototype portion of the CustomerController. How would I go about initializing an instance of this class? What other "Nop" related calls and stuff must I setup?

#region Ctor

        public CustomerController(IAuthenticationService authenticationService,
            IDateTimeHelper dateTimeHelper,
            DateTimeSettings dateTimeSettings, TaxSettings taxSettings,
            ILocalizationService localizationService,
            IWorkContext workContext, ICustomerService customerService,
            ITaxService taxService, RewardPointsSettings rewardPointsSettings,
            CustomerSettings customerSettings, ForumSettings forumSettings,
            OrderSettings orderSettings, IAddressService addressService,
            ICountryService countryService, IStateProvinceService stateProvinceService,
            IOrderTotalCalculationService orderTotalCalculationService,
            IOrderProcessingService orderProcessingService, IOrderService orderService,
            ICurrencyService currencyService, IPriceFormatter priceFormatter,
            IPictureService pictureService, INewsLetterSubscriptionService newsLetterSubscriptionService,
            IForumService forumService, IShoppingCartService shoppingCartService,
            IOpenAuthenticationService openAuthenticationService, MediaSettings mediaSettings,
            IWorkflowMessageService workflowMessageService, LocalizationSettings localizationSettings,
            CaptchaSettings captchaSettings, ExternalAuthenticationSettings externalAuthenticationSettings)
        {

Hi,

nopCommerce is using Dependency Injection and this is being controlled by AutoFac (http://code.google.com/p/autofac/) container.

If you're not familiar with Dependecy Injection, it's worth a bit of reading!

Wiki
http://en.wikipedia.org/wiki/Dependency_injection

Martin Fowler
http://martinfowler.com/articles/injection.html


You'll notice all the parameters in the construct are interfaces, when nopCommerce starts up it registers these interfaces with the dependency container - have a look at class DependencyRegistrar in Nop.Web.Framwork.

Whenever a Controller is requested, the NopDependencyResolver class is responsible for constructing the instance. This then looks in the container and determines what concrete classes are registered for the interfaces. e.g.

builder.RegisterType<CustomerService>().As<ICustomerService>().InstancePerHttpRequest();

An instance of CustomerService is sent to the controller whenever ICustomerService is found in a construct.

So, the dependency framework is responsible for passing parameters to the controller. It's a very powerful concept, particularly where you have dependecy chains, e.g.

ICustomerService uses IRepository<Customer> uses IDbContext etc....

The framework will inject all of the parameters in your entire chain, you don't have to do anything :).

It's a very common pattern, it allows unit testing by allowing us to provide different classes that implement the interfaces. This aheres to the Open/Closed principle http://en.wikipedia.org/wiki/Open/closed_principle, we can change the behaviour of classes by providing different implementations

It can seem a bit automagical until you get your head around the container and how parameters are resolved.

The 2 classes that do all the wiring up in nopCommerce are DependencyRegistrar (this is where you wire up your container) and NopDependencyResolver (this creates instances of controllers etc and uses the container to resolve parameters)


Hope that helps

Thanks dmorley! I am not familiar with Dependency Injection and will be reading up. I noticed the System.Reflection's and DependencyRegistrar class, etc. and was suspecting 'something' like that - maybe - idunno - lol!

That is totally an awesome concept. Yes, a little unnerving at first but also very powerful and abstract. This is more than enough to get me going in the right direction.


Nice score for me in the Nop forums...Thanks again!

Thanks dmorley! Exactly what I needed to know.

So, for anyone else reading, if you need an object, then you can add a line such as:

IPdfService pdfService = EngineContext.Current.Resolve<IPdfService>();

@clermontsoftware

Using .Resolve<...>() should be a last resort - i.e. if you can't/don't want to change a View, or a have a circular reference.
Use dependency injection.

dmorley wrote:

was that class NopDependencyResolver  replaced or renamed? I cant find it in 3.5 version.