Hi there!
My team is building a custom e-commerce solution based on nopCommerce 3.7 (we are in progress with migration to 4.1).
We have some disputes inside the team regarding how to properly extend core NOP functionality. We follow a plugin based approach with any customization: whenever you want to change smth in NOP - create a new custom plugin (or update if it's already created). Let's imagine the simple situation with adding new text property to the user profile.
Current approach which we follow:
- If this part hasn't been changed yet - we create a new custom plugin
- Copy paste all web layer (models, controllers, etc) and data layer related to the user profile
- Add a new property to our copied models
- Update route config to direct our users to our custom implementation
And it works, but it looks so dirty and doesn't attract at all, because we have such a vast code duplication,
build time about to increase because of the number of plugins (we try to keep areas separated in the scope of modules) and so on. Even debug session not always looks straightforward and clear.
So the question is how to handle it less painful?
I would appreciate if you can share your experience or direct me to some detailed guidance.
I think plugins based approach for customization is excellent when you need to exactly make some changes in NOP behavior and not just extend existing models and controller actions with a couple of new properties and a couple lines of code which sets these properties.
Note:
I'm a newbie with NOP and I like this platform and ecosystem around it.
I know it's very harmful to change the original code of NOP because there are a lot of plugins which relies on it,
but do we really avoid this situation with the plugin based approach - IMHO, I don't think so, because it looks like we just increase the amount of codebase size and complexity. Even with migration to major versions, I also don't find this approach very helpful, and I assume it won't help a lot due to platform changes, even with huge attention and care to back-compatibility from the NOP team.
Regards,
Max
Proper way to extend NOP functionality
Team Member
- 16619
- 155940
- 10/22/2008
- Armenia
Hi Max,
It depends on several factors. Briefly saying:
Consider plugins when:
1. You continuously upgrade to the latest versions of nopCommerce (when released). It'll be faster with plugins
2. You have enough experience with nopCommerce because it's a little bit more complex. Or simply if you want to demonstrate that you can write plugins.
3. You want to sell it as a plugin on our marketplace
Consider core customization when
1. You're limited in time
It depends on several factors. Briefly saying:
Consider plugins when:
1. You continuously upgrade to the latest versions of nopCommerce (when released). It'll be faster with plugins
2. You have enough experience with nopCommerce because it's a little bit more complex. Or simply if you want to demonstrate that you can write plugins.
3. You want to sell it as a plugin on our marketplace
Consider core customization when
1. You're limited in time
Certified Developer
- 7
- 75
- 6/1/2017
- United States
Given that this is an incredibly broad question, I'm not really sure what's being asked but can offer some points.
First, adding a new property to the user profile is possible through Nop's Custom Customer Attributes which you can set from the Admin side under Settings >> Customer Settings.
But a more a big picture point is you don't have to copy any models and controllers related to anything in core Nop that you want to extend.
There are many ways to extend Nop (without modifying the core) for reasons like the example you stated.
Overriding a view is as easy as registering a new route with the same RouteTemplate you wish to replace within your plugin's IRouteProvider and directing the request to your plugin's controller which would return your plugin's view. Or if your team is rolling their own Nop Theme, just having their own version of any view present in Nop's default Views folder will override that view.
As far as extending any view models go, every Model in Nop.Web inherits the BaseNopModel class which has a CustomProperties Dictionary for you to reference. So you could try messing with that. Or you could define a new Model in your plugin which inherits from the base Nop viewmodel you wish to extend.
Then there's the GenericAttributes table, where you can save whatever extraneous stuff you may need that doesn't fit in with any default Nop tables. Your plugin could also create its own tables that extend any default Nop entities.
The only situation I can think of that would necessitate altering Nop's core would be if you absolutely had to add a column to one of the tables in the database for performance reasons or otherwise.
If you have a more specific question I could offer more detail, but the Nop solution is already cumbersome to clean and build in VS as is, so copying an entire data layer is going to bring your build times to a brutal pace.
First, adding a new property to the user profile is possible through Nop's Custom Customer Attributes which you can set from the Admin side under Settings >> Customer Settings.
But a more a big picture point is you don't have to copy any models and controllers related to anything in core Nop that you want to extend.
There are many ways to extend Nop (without modifying the core) for reasons like the example you stated.
Overriding a view is as easy as registering a new route with the same RouteTemplate you wish to replace within your plugin's IRouteProvider and directing the request to your plugin's controller which would return your plugin's view. Or if your team is rolling their own Nop Theme, just having their own version of any view present in Nop's default Views folder will override that view.
As far as extending any view models go, every Model in Nop.Web inherits the BaseNopModel class which has a CustomProperties Dictionary for you to reference. So you could try messing with that. Or you could define a new Model in your plugin which inherits from the base Nop viewmodel you wish to extend.
Then there's the GenericAttributes table, where you can save whatever extraneous stuff you may need that doesn't fit in with any default Nop tables. Your plugin could also create its own tables that extend any default Nop entities.
The only situation I can think of that would necessitate altering Nop's core would be if you absolutely had to add a column to one of the tables in the database for performance reasons or otherwise.
If you have a more specific question I could offer more detail, but the Nop solution is already cumbersome to clean and build in VS as is, so copying an entire data layer is going to bring your build times to a brutal pace.