How to work with NopCommerce MVC as a team

We are currently looking at the latest version (2.60) of NopCommerce in MVC, and we will integrate it soon ... Weve downloaded the source code and paid $ 20 for the documentation of the User Guide. The documentation is great! I mean ... it's great in the sense that it explains how to deploy, install, and how to work with the interface and backend. This is great for a general overview, but it lacks an understanding of how to work with NopCommerce as a team. What is / - best practices, etc.

As an example (or parallel), if you decide to work with Dotnetnuke as a command, you usually work as follows:

  • Each developer downloads / installs Dotnetnuke locally on their machine.
  • You can also download / install Dotnetnuke on a dedicated server (say, a Dev server).
  • As a developer, you work and create modules that you test locally in your Dotnetnuke installation.
  • Once this is done, you will package your module (and any SQL scripts that come with your module) in a zip file.
  • Once the package is ready, you download / install this package on a dedicated server (dev-server).

This approach is great for Dotnetnuke and, more importantly, if you have a development team creating modules.

My question is, how does the team work with NopCommerce MVC?

I assume that it is a bad idea to work directly inside the source code if your team decides to change the main elements / source that will make it impossible to upgrade to newer versions (or break the changes).

I'm not sure that my parallel with Dotnetnuke is correct ... but someone might think (or help me clarify) how the team works with NopCommerce MVC.

Also, if the team relies solely on creating plugins for NopCommerce and avoids kernel changes, or should this be inappropriate?

How to add new objects to SQL (or modify existing ones), should we prefix our objects in case a possible update of NopCommerce MVC creates similar objects and / or overwrites them?

Thanks for helping me shed some light on this.

respectfully

Vince

+6
source share
1 answer

Plugins in NopCommerce are almost similar to modules in DNN. Depending on what you need to do, sometimes you need to change the main code.

What I did for the services was to create a new class and inherit from the existing service, and then override the function you want to change. Create a new DependencyRegistrar class and set the new service classes as an implementation for this particular interface. Also make sure the Order property is 1 so that your DR class is loaded after stock. Since you inherit the main class, any functions that you have not redefined will be handled by the parent class. If I need to add a new function, I simply modify the interface by putting a stub in the stock class and implementing it myself.

Views in the Nop.Web project can be canceled by Themes. Administration and web controllers are becoming more complex. I just modify these files directly.

The Core and Data classes can be made using partial classes to add new fields.

In any case, you still have to combine the changes with your decision when releasing the update. My opinion is that you better write clean, readable code now and bite the merge bullet when it arrives.

I'm really not worried about SQL scripts right now, because I'm one developer, but maybe you add a folder for ALTER scripts and name them after the day they were created. Each developer then knows which scripts they need to run when they receive the latest version.

+6
source

Source: https://habr.com/ru/post/921944/


All Articles