Understanding the work context

Hi,

I am working through the customer registration, login, creation, etc.  And I am strugging to understand where the settings are loaded.  I managed to track my way down to the global.asax.cs file, it seems that it is set some where in SetWorkingCulture method.

Why are things done this way?  Where do I go and read up on this method/patterns used?  Is it like a bootstrapper the way it was done like this?  I am trying to understand the way the settings are loaded and getting the customer, so any extra articles that you can recommend please let me know :)

Thanks
Brendan

https://www.nopcommerce.com/docs/71/source-code-organization-architecture-of-nopcommerce.aspx

This has nothing to do with my question!

Do you mean the settings that are used to control behavior in nopCommerce or the database settings?

Database settings are loaded in Nop.Core.Data.DataSettingsManager and app settings are saved in the DB and loaded from Nop.Services.Configuration.SettingsService

If you ever need to know the currently logged in Customer, inject IWorkContext and check the CurrentCustomer property.

Thanks.

I see that there are customer settings that are injected in the customer controller.  When are these values retrieved from the database?  I'm trying to find my way around the start up of the project.  When I put a break point on the customer controller's constructor then the customer settings are already set.  Where do you set these customer settings and when?

Just another question, I am also trying to understand the engine context and the work context.  What patterns/method are being followed here?  I would like to know so that I can go and Google to find more info on why it was done this way?

The engine context makes use of a singleton pattern.  Is this an anti-pattern?

nopCommerce is doing Dependency Injection via the Autofac library.  What happens is you create a constructor with all of the interfaces you want and the dependency manager knows what classes to use for those.  It instantiates each one, fills their own dependencies, and then supplies them in the constructor for your class or service.

You can see how the dependencies are registered in Nop.Web.Framework.DependencyRegistrar.cs

The benefit to this whole thing is when you are writing a service, you don't care how these other services actually work as long as they give you the result you want.  Let's say you use the IOrderProcessingService and call the PlaceOrder function.  You don't really need to know what happens in there as long as you give it a ProcessPaymentResult and it gives you back a PlaceOrderResult.

I wanted my order processing to work differently so I made a new class, changed the dependency registrar to use mine instead of nop's, and then you're done.  None of the other services' code has to change because they depend on the interface instead of a specific class.

bioluminescence wrote:

Why would it be?  It's handling things for the structure of the website and not any particular customer or user.  You only want there to be one of them.

Ok thanks.

What is the duties and roles of the engine context and work context?  Also let say we were to run different types of applications (like web, service, silverlight), which of these contexts will be used.

Sorry for all these questions, but I need to understand the app :)

I'll try to answer but this starts getting down to more of the infrastructure that I don't look at each day.

NopEngine running the scheduled tasks and managing the DI container.  I believe it runs as a singleton.
WorkContext is just some basic info on the customer that is using the site at the time ie which Customer they are, what language they are using, if they're an Admin.  There is probably a different WorkContext for each incoming Request.