A nopCommerce architecture question when doing customization

I am an experienced MVC developer in ecommerce area, and recently started fresh with nopCommerce 3.1. I have never used this product before, and still getting my hands around in certain area.

In NC, is it possible to write a CustomController that inherit the "core controller" and ask IoC to register the CustomController in place of CoreController?

eg. with CatalogController, is it possible to write my own CustomCatalogController that inherit from CatalogController and with IoC, the view will automatically pickup the custom class?

I spent a few days with NP now, and my feeling is it may not be possible as it uses the plugin approach, but I still want to ask around making sure I am not missing anything here, as I heard comments that it is meant to be easy to do customizations.

Sometimes I want to add more services, or extend a model with an existing controller and plugin approach don't always work in those situation.

Ideally I want to leave Nop.Admin, Nop.Web and Nop.Web.Framework untouch and write my own My.Admin My.Web etc that inherit the core classes, but the ctor fields are set to private not protected, that's why it made me thinking this approach might not work.

Any thoughts?

EDIT: In page 2, I proposed a solution for clean customizations for services and helpers. Any feedbacks would be appreciated.

This is something I'm exploring as well.  I'm thinking that there is no IoC container that resolves the Controller type, so that it's the MVC framework itself that finds the controller.  Check out the core routes here:

\Presentation\Nop.Web\Infrastructure\RouteProvider.cs

Perhaps in your plugin's RouteProvider there is a way to unregister the route and register the one in your namespace like so:  http://stackoverflow.com/questions/1417895/remove-or-replace-existing-routes-in-routetable

hobbes wrote:

Hello,

I also found I can modify this file to change the namespace of the controller that it picks up, and especially useful if you name your custom controller the same name as the core one but only change the namespace, it will pick up the correct view with the same path!!

I am just a little or very little disappointed that core controllers do not have the methods set to virtual and some properties are private, that indicate me that the author did not build the core controller in a mind that people are doing customization or maybe overriding them.

It is not a big deal afterall, but the NC website said that this package is easy for customization, and I can tell the plugin modules are really awesome, so I am thinking maybe building my own controller is not the correct way to do customization and wanted to see what everyone else out there using it, since I am fairly new to NC, just been using it for like 10 days only.



Sunny

Thanks Both of you. inspired me a lot.

I've been facing a similar problem with controllers. NC is a really nice framework for customerization.

Models and veiws are really easy to overwrite in themes. core services are really easy to overwrite with IoC in plugins.  It seems controller is the missing link.

It there a 'clean' way to overwrite contollers in NC at all?

xzhang wrote:

Wrote this 2 days ago.

http://tech.sunnyw.net/2013/11/nopcommerce-customization-with.html (UPDATED)

I don't think it can be clean in NC with 100% hotswap, but at least not so dirty.

I also found that the controller in NC are set to partial, so in some scenarios, you maybe able to get away with a "hook" and partial, if you understand what I meant.

I am actually quite keen to hear what other people do / say around the globe, I am sure these kind of things must be done many times by many people, so surely there got to be some standard way to do it. (besides plugins)


Sunny

Hi Sunny,

Is there a chance that you can post your blog post here? I cannot access the page:

http://sunnyw.wordpress.com/ is marked private by its owner. If you were invited to view this site, please log in below. Read more about privacy settings.

Thanks,
Steven

Since controllers don't implement an interface, the IOC container doesn't have anything to resolve to

Have you considered just creating a custom route override? Say you create CatalogExts which inherits Catalog, could you not simply force your routing to resolve Catalog/ to CatalogExts?

Yes, you would be modifying the core files, but not very much.

mattsoundworld wrote:

That's basically what I am doing now, but being a noob in Nop, I thought there are better way to do it and seems not.

Sunny

I have found a good way to customize NopCommerce that me and my team now use on every project we work on.

I involves creating partials for everything including Controllers, Services and even Core Domain classes.

For example:
- If you want to add more columns in the product table: create a folder inside Nop.Core called "Custom". Re-create the subfolders of the partial for example "Domain". And create a partial class called Product.Partial.cs. Add more fields as necesarry.

- If you want to create new service methods or modifying them: create a folder inside Nop.Services called "Custom". Re-create the subfolders of the partial class for example "Catalog". And create a partial interface and a partial class called IProductService.Partial.cs and ProductService.Partial.cs and create new methods in there.

- If you want to modify controllers: create a folder inside Nop.Web called "Custom". Re-create the subfolders of the partial controller for example "Controllers". And create a partial class called "CatalogController.Partial.cs" and add new Action methods. If you need to replace an existing method modify the original file by adding an attribute to the method:

        [ActionName("CategoryOriginal")]
        [NopHttpsRequirement(SslRequirement.No)]
        public ActionResult Category(int categoryId, CatalogPagingFilteringModel command)
        {

In your partial you need to create a new method with a different name but using the original action name attribute for example:

        [ActionName("Category")]
        [NopHttpsRequirement(SslRequirement.No)]
        public ActionResult CategoryNew(int categoryId, int? categoryId1, int? categoryId2, CatalogPagingFilteringModel command)
        {

Other things like RouteProvider, DependanceRegister or Tasks don't need partials. You only need to implement their interfaces.

Some disadvantages:

- In involves *minimal* changes to its core files
- It is not the proper way to do it.

Some advantages:

- It is quicker and easier than plugins
- It possible to keep upgrading it
- It is tried and tested and works

Hi Carlos,

That's a great suggestion. I think it's certainly less hassle than having to inherit from the Controller and modifying the properties from private to protected.

cheers for the tip
Steven