我们目前正在寻找MVC中NopCommerce的最新版本（2.60），我们很快就会整合它......我们已经下载了源代码，并为用户指南文档支付了20美元。文档很棒！我的意思是......从某种意义上讲，它解释了如何部署，安装以及如何解决UI前端和后端问题。这对于整体概述非常有用，但缺少的是了解如何与团队合作NopCommerce。什么是最佳实践等...
作为一个例子（或并行），如果您决定与Dotnetnuke合作，您通常以下列方式工作：
这种方法对Dotnetnuke很有用，更重要的是如果你有一个开发人员团队创建模块。
我的问题是团队如何与NopCommerce MVC合作？
我认为直接在源代码中工作是个坏主意，以防你的团队决定修改核心元素/来源，这将导致无法升级到新版本（或中断更改）。
我不确定我与Dotnetnuke的平行是否是正确的...但是，任何人都有任何想法（或帮助我澄清）团队如何与NopCommerce MVC合作。
此外，团队是否应该仅依赖于为NopCommerce创建插件并远离修改核心，还是应该与此无关？
如果在最终NopCommerce MVC升级创建类似对象和/或覆盖它们的情况下，我们应该在对象前添加前缀，如果在SQL中添加新对象（或修改现有对象）呢？
感谢您帮我解释一下。
此致
文斯
答案 0 :(得分：6)
NopCommerce中的插件几乎就像DNN中的模块一样。根据您的需要，有时需要修改核心代码。
我为服务做的是创建一个新类并从现有服务继承，然后覆盖您想要更改的功能。创建一个新的DependencyRegistrar类，并将新的服务类设置为该特定接口的实现。还要确保Order属性为1，以便在库存之后加载DR类。由于您是从核心类继承的，因此您未覆盖的任何函数都将由父类处理。如果我需要添加一个新函数，我只是修改接口，在库存类中放置一个存根，并在我自己实现它。
Nop.Web项目中的视图可以被主题覆盖。管理员和Web控制器变得更加棘手。我只是直接修改这些文件。
Core和Data类可以使用partial类来添加新字段。
在任何情况下，您仍需要在发布更新时将更改与解决方案合并。我的观点是，你最好现在编写干净，可读的代码，并在它出现时咬合并子弹。
我现在并不担心SQL脚本，因为我是单个开发人员，但也许您为ALTER脚本添加了一个文件夹，并在创建它们之后命名它们。然后每个开发人员都知道他们最新的时候需要运行哪些脚本。