Как работать с nopCommerce MVC в команде

в настоящее время мы смотрим на новейшую версию (2.60) NopCommerce в MVC, и мы будем интегрировать его довольно скоро...мы загрузили исходный код и заплатили 20$ за документацию руководства пользователя. Документация отличная! Я имею в виду ... это здорово в том смысле, что он объясняет, как развертывать, устанавливать и как работать вокруг интерфейса пользовательского интерфейса и бэкэнда. Это отлично подходит для общего обзора, но ей не хватает понимания, как работать с ней в команде. Какие есть лучшие практики и т. д...

в качестве примера (или параллели), если вы решили работать с Dotnetnuke в команде, вы обычно работаете следующим образом:

  • каждый разработчик загружает / устанавливает Dotnetnuke локально на своих машина.
  • вы также загружаете / устанавливаете Dotnetnuke на выделенный сервер (скажем dev-server).
  • как разработчик, вы работаете и создаете модули, которые вы тестируете локально внутри вашего Dotnetnuke установка.
  • как только это будет сделано, вы упакуете свой модуль (и любые сценарии SQL, которые поставляется с модулем) в zip-файл.
  • как только пакет готов, вы загружаете / устанавливаете этот пакет на выделенный сервер (dev-server).

этот подход отлично работает для Dotnetnuke и, что более важно, если у вас есть команда разработчиков, создающих модули.

мой вопрос в том, как команда работает с nopCommerce MVC?

Я предполагаю, что это это плохая идея напрямую работать в исходном коде, если ваша команда решит изменить основные элементы / источник, который сделает любое обновление до более новых версий невозможным (или сломает изменения).

Я не уверен, что моя параллель с Dotnetnuke является правильной...но кто-нибудь имеет представление (или поможет мне уточнить), как команда работает с NopCommerce MVC.

кроме того, должна ли команда полагаться только на создание плагинов для NopCommerce и держаться подальше от изменения ядра или должна это не имеет значения?

Как насчет добавления новых объектов в SQL (или изменения существующих) должны ли мы префикс наших объектов в случае возможного обновления nopCommerce MVC создает аналогичные объекты и/или перезаписывает их?

Спасибо, что помогли мне пролить свет на это.

с уважением

Винс

1 ответов


плагины в NopCommerce почти как модули в DNN. В зависимости от того, что вам нужно сделать, иногда необходимо изменить основной код.

то, что я делал для служб, - это создание нового класса и наследование от существующей службы, а затем переопределение функции, которую вы хотите изменить. Создайте новый класс DependencyRegistrar и задайте новые классы служб в качестве реализации для этого конкретного интерфейса. Также убедитесь, что свойство Order равно 1, чтобы ваш DR класс загружается после запасного. Поскольку вы наследуете от основного класса, любые функции, которые вы не переопределили, будут обрабатываться родительским классом. Если мне нужно добавить новую функцию, я просто изменяю интерфейс, помещая заглушку в класс stock и реализуя ее в своем собственном.

представления в Nop.Веб-проект может быть переопределен темами. Администратор и веб-контроллеры становятся сложнее. Я просто изменяю эти файлы напрямую.

ядро и данные классы можно сделать с помощью частичных классов, чтобы добавить новые поля.

в любом случае вам все равно нужно будет объединить изменения с вашим решением при выпуске обновления. Мое мнение, что вам лучше писать чистый, читаемый код сейчас и кусать пулю слияния, когда она приходит.

Я не очень беспокоюсь о сценариях SQL прямо сейчас, потому что я один разработчик, но, возможно, вы добавляете папку для ALTER scripts и называете их после дня их создания. Затем каждый dev знает, какие сценарии им нужно запустить, когда они получат последние.