Объединение общего проекта с вариантами построения в .NET MVC

Ответ 1

Я бы использовал либо несколько проектов, либо nuget, либо использование элемента управления source. Я расскажу об этих идеях ниже, но не в определенном порядке. К концу я могу включить предпочтение в отношении того или другого.

Первая идея, о которой я расскажу, - использовать несколько проектов. Создайте свой базовый проект, позвольте ему называть его WebBase. Создайте свой основной сайт, о котором вы говорили. Затем создайте сайт Customer1, если вы создадите Customer1 в качестве пустого веб-сайта, вам нужно будет воссоздать структуры папок в WebBase, или вы можете создать его так же, как и с WebBase, и удалить все файлы (сделайте это из Visual Studio); в любом случае вы получаете структуру папок без файлов. Я бы порекомендовал держать web.config, packages.config, папку свойств с AssemblyInfo.cs. Затем вы добавите файлы из WebBase, но не добавляйте их обычно. В целях иллюстрации сделайте представление Home Index: разверните папку Views в Customer1, щелкните правой кнопкой мыши по дому, выберите add, выберите Exising Item, просмотрите Customer1, а затем в WebBase/Views/Home и один клик index.cshtml, теперь обратите внимание на выпадающую кнопку? щелкните это и выберите "Добавить как ссылку". Теперь сделайте это для всех файлов в WebBase! Кажется громоздким выбирать "добавлять как ссылку" каждый раз, но если вы просто нажмете "добавить", он скопирует файл, и обновления не будут распространяться с WebBase на Customer1! Кроме того, вы увидите такие вещи, как remove from project vs delete (с подсказкой о постоянном удалении).

Вторая мысль заключалась в том, чтобы создать пакет nuget для WebBase, и вы можете установить его как пакет, преимущество такого подхода - управление версиями, и это не потребует, чтобы вы обновляли каждый проект с каждым небольшим изменением. Это полностью изолировало бы каждый проект. Вниз - вам нужно будет обновлять каждый проект отдельно, чтобы распространять изменения во всем мире. Вам нужно будет узнать о файле nuget nuspec и о том, как включать файлы и т.д. Это не так уж плохо, это просто XML. Но вы можете указать, какие файлы следует включать, когда пакет установлен/обновлен.

В-третьих, это будет контроль источника, я знаю, что с помощью git вы можете использовать подмодуль для включения отдельного проекта (даже из внешнего репозитория). Какой может быть вариант, или вы можете просто создать ветвь WebBase, настроить WebBase и затем разделить его на каждый сайт клиента. Поэтому создайте ветвь Customer1, начните добавлять пользовательские вещи клиента. Вернитесь в WebBase, создайте новую ветку Customer2... вы отправитесь на гонки. Вернитесь к WebBase, сделайте глобальное изменение и затем объедините эти изменения в ветки Customer1 и Customer2.

Хорошо, я признаю это, я, вероятно, поеду с третьим вариантом. Это дает вам много преимуществ с небольшим недостатком. Это даже дает вам историю! Если вы в настоящее время не используете источник управления... вы должны! Вы можете установить git на свой компьютер и иметь возможность проверять код на локальном компьютере, и вам не нужно беспокоиться о внешнем репозитории (хотя я бы порекомендовал вам его, поскольку он дает вам DR).

В любом случае есть варианты. Но ничто не похоже на один проект с настраиваемым файлом.

Удачи!

Ответ 2

Первое, что приходит в голову (и, вероятно, проще всего, потому что оно не требует каких-либо дополнительных инструментов), заключается в создании основного проекта с основными функциональными возможностями, представлениями и контроллерами. И для каждого клиента создается отдельный проект с пользовательскими представлениями и контроллерами. Затем для проекта, специфичного для клиента, просто соедините все необходимые файлы с основным проектом. Может быть немного утомительно связывать файлы в зависимости от числа, но кажется выполнимым.

Другим подходом может быть использование таких инструментов, как CAKE или FAKE, с помощью которого вы можете script весь процесс сборки так, как вы хотите, но я никогда не пробовал делать такие собственные скрипты самостоятельно.

Третий вариант, который я могу работать, - это условно включить файлы на основе определенной константы, но для этого потребуется редактировать файлы *.csproj. Код может выглядеть примерно так:

<Content Include="Views\View1.cshtml" />
<Content Include="Views\View2.cshtml" Condition="$(DefineConstants.Contains('CORE'))" />
<Content Include="Views\View2.cshtml" Condition="$(DefineConstants.Contains('CUSTOMER1'))" />
<Content Include="Views\View3.cshtml" Condition="$(DefineConstants.Contains('CORE'))" />
<Content Include="Views\View3.cshtml" Condition="$(DefineConstants.Contains('CUSTOMER1'))" />

Не уверен, насколько легко будет поддерживать его.

Я бы, вероятно, подумал о том, чтобы разделить приложение на независимые компоненты/проекты, которые будут содержать все функциональные возможности, связанные с компонентом. Во время сборки составьте компоненты с FAKE на основе того, какие компоненты необходимы для конкретного клиента.

Ответ 3

Ваше требование - отличный кандидат для настраиваемого шаблона проекта Visual Studio.

Я подумываю о подготовке одного большого проекта со всеми функциями, которые вы развертываете для любого клиента. Этот проект также может быть туловищем, который вы можете обновить, когда потребуется новая функция или исправление. Затем экспортирует магистральное решение в шаблон. Затем продолжите шаблон проекта VSIX и включить в него мастер, для сбора пользовательского ввода при создании проекта. На основе ввода выполните соответствующие действия и добавьте/удалите необходимые файлы или включите/отключите функции по мере необходимости.

Или вы можете просто сохранить исходные файлы в файловой системе и упорядочить их в шаблоне "на лету", т.е. в результате ввода пользователем во время работы мастера. В конце мастера развернут шаблон и... вуаля.

Ответ 4

Что вам нужно, это раздел супер-админ, где вы можете [de] активировать разные части сайта, в зависимости от клиента.

Ответ 5

Здесь есть несколько действительно хороших ответов на код, но если вы хотите создать автоматизированную систему сборки для каждого клиента, и у вас есть нагрузки, это может быть слишком уж больно. Когда вы можете настроить script для Powershell, который может это сделать

псевдокод

For each client site
    download base code to code/
    download this client changes to code/ overwriting files
    msbuild ....
    copy client/ bin to build/client/
    Delete code/
End For each

Ответ 6

Ответ на этот вопрос требует некоторых нововведений. Поэтому посмотрите на мое решение:

Настройте основную структуру проекта для классов, которые охватывают файлы Модель и Контроллер, а затем используйте их с техникой Добавить существующий элемент как ссылку, который может делиться следующими словами:

• Логика приложений, общая для обоих приложений, но не переносимая
• Пользовательские элементы управления без зависимостей платформы

К сожалению, это не поддерживается для бритв views. Таким образом, проще всего копировать общие представления - иметь несколько файлов макета, например, известный файл _Layout.cshtml, по одному в каждом веб-приложении. Вы также можете Скомпилировать представления asp.net mvc Razor в отдельной dll, чтобы использовать их как ссылку (как общие представления).

Для Активы вы можете разместить все свои таблицы стилей (и некоторые javascript, если это необходимо) из основного веб-приложения и получить доступ к нему из каждого веб-приложения.

В папке bin имеются файлы метаданных MVC, а также те, которые вы добавляете для использования в своем проекте, и файл projectName.dll, который будет создан после создания. Вы можете просто добавить/удалить их, щелкнув правой кнопкой мыши на ссылке, используя инструмент "Добавить ссылку".