Cómo trabajar con NopCommerce MVC como equipo

Question

Actualmente estamos viendo la versión más reciente (2.60) de NopCommerce en MVC y la vamos a integrar muy pronto ... Hemos descargado el código fuente y pagado los 20 $ por el Documentación de la guía del usuario. ¡La documentación es genial! Quiero decir ... es genial en el sentido de que explica cómo implementar, instalar y cómo trabajar alrededor de la interfaz de interfaz de usuario y el back-end. Esto es ideal para una visión general, pero lo que le falta es la comprensión de cómo trabajar con NopCommerce como equipo. ¿Cuáles son/es de las mejores prácticas, etc ...

A modo de ejemplo (o paralelo), si decide trabajar con DotNetNuke como un equipo, por lo general trabaja de la siguiente manera:

• Cada desarrollador descarga/instala Dotnetnuke localmente en su máquina .
• También descarga/instala Dotnetnuke en un servidor dedicado (digamos dev-server).
• Como desarrollador, usted trabaja y crea módulos que prueba localmente dentro de su instalación de Dotnetnuke.
• Una vez hecho, empaqueta su módulo (y cualquier script SQL que viene con su módulo) en un archivo zip.
• Una vez que el paquete esté listo, cargue/instale ese paquete en el servidor dedicado (dev-server).

Este enfoque funciona muy bien para Dotnetnuke y más importante aún si tiene un equipo de desarrolladores que crean módulos.

Mi pregunta es cómo funciona un equipo con NopCommerce MVC?

Supongo que es una mala idea trabajar directamente con el código fuente en caso de que su equipo decida modificar los elementos/fuente principales, lo que imposibilitará cualquier actualización a las versiones más nuevas (o romperá los cambios).

No estoy seguro de si mi paralelo con Dotnetnuke es correcto ... pero cualquiera podría tener alguna idea (o ayudarme a aclarar) cómo funciona un equipo con NopCommerce MVC.

Además, ¿el equipo solo debe confiar en la creación de complementos para NopCommerce y evitar modificar el núcleo o debería ser irrelevante?

¿Qué tal si agregamos nuevos objetos en SQL (o modificamos los existentes) deberíamos prefijar nuestros objetos en caso de que una eventual actualización de NopCommerce MVC cree objetos similares y/o los sobrescriba?

Gracias por ayudarme a arrojar algo de luz sobre esto.

Atentamente

Vince

Answer 1

plugins en nopCommerce son casi como módulos en DNN. Dependiendo de lo que necesite hacer, a veces es necesario modificar el código central.

Lo que he estado haciendo para los Servicios es crear una nueva clase y heredar del servicio existente, luego anular la función que desea cambiar. Cree una nueva clase DependencyRegistrar y configure sus nuevas clases de servicio como la implementación para esa interfaz en particular. También asegúrese de que la propiedad Order sea 1 para que su clase DR se cargue después del stock. Dado que hereda de la clase principal, cualquier función que no haya anulado será gestionada por la clase principal.Si necesito agregar una nueva función, solo estoy modificando la interfaz, poniendo un resguardo en la clase de stock e implementándolo en mi propia cuenta.

Las vistas en el proyecto Nop.Web pueden anularse por Temas. El material de administración y los controladores web se vuelven más complicados. Solo estoy modificando esos archivos directamente.

Las clases de Núcleo y Datos se pueden hacer usando clases parciales para agregar sus nuevos campos.

En cualquier caso, aún deberá fusionar los cambios con su solución cuando se lance una actualización. Mi opinión es que es mejor escribir código limpio y legible ahora y morder la bala de fusión cuando se trata.

Realmente no me preocupo por las secuencias de comandos SQL en este momento porque soy un desarrollador único, pero tal vez agregue una carpeta para las secuencias de comandos ALTER y asígneles un nombre después del día en que se crearon. Entonces, cada desarrollador sabe qué scripts necesitan para ejecutar cuando son más recientes.