В Visual Studio 2015 я стал отдавать предпочтение проектам веб-сайтов, а не проектам веб-приложений. Я все еще использую Visual Studio, хотя, поскольку вы получаете Nuget Packaging, вы можете устанавливать пакеты Nuget для обоих типов проектов.
Однако у проекта WebSite нет файла проекта, вы буквально просто добавляете папку в свое решение.
Однако у вас все еще может быть код, но я предпочитаю помещать его в отдельный проект.
В проектах WebApp у вас есть ваши активы, CSS, виды (бритва, aspx и т. Д.), Контроллеры / кодовые элементы и т. Д., Все в одном проекте, и он просто объединяется. Я предпочитаю работать с сайтами в две половины. Внешний интерфейс (css, js, images, "html / cshtml / aspx / ashx / .master / etc") и внутренний конец (весь код).
Поэтому я создаю проект веб-сайта и библиотеку классов для его сопровождения (в visual studio вы можете добавлять ссылки на проект веб-сайта). Я добавляю свою библиотеку классов как зависимость, и весь код находится в классе Library. У вас все еще может быть global.asax, вы просто должны сказать ему, что код находится в другой dll (не той, в которую будет компилироваться сайт). Представления MVC, вы просто указываете пространства имен, как обычно (dll - это ссылка, поэтому пространства имен есть). А в WebForms вы просто должны помнить, чтобы включить имя сборки в ссылки на тип, в котором находится код.
Это немного утомительно, чтобы привыкнуть, но когда у вас есть изолированная структура, все находится в месте, которое имеет смысл, и модульное в удобном для обслуживания виде.
И плюсом является то, что, поскольку веб-сайт - это просто папка (без файла проекта), его можно легко открыть в коде Visual Studio и других популярных текстовых редакторах, облегчающих работу дизайнеров над css / js / изображения и т. д. (которых нет в проекте кода). Разделяя дизайнеров слоев, дизайнер видит то, что им нужно.
Теперь структура мудрая. Я держу свой код локально на своей машине, проверенный в хранилище subversion, используя Tortoise SVN и Visual SVN (магазин java / .net). Для локального тестирования я устанавливаю IIS и настраиваю проект веб-сайта в IIS локально, как на серверах dev / prod.
Затем я устанавливаю MSDeploy на серверах dev / prod и использую функцию публикации веб-приложения через MSDeploy в visual studio и использую преобразования web.config. Поэтому у меня есть преобразования web.config для dev и prod, а основной web.config без преобразований предназначен для локального тестирования (поэтому он работает для всех разработчиков проекта).
К предыдущим заявленным минусам: наличие проекта WebSite против проекта WebApp не означает, что несколько разработчиков не могут работать с ним, это только в том случае, если ваш проект WebSite находится на каком-то сервере, и вы загружаете его непосредственно оттуда, что было бы плохой практикой.
Вы можете относиться к проекту WebSite точно так же, как к любому другому проекту Visual Studio, локальному коду, управлению исходным кодом, нескольким разработчикам.
В качестве заключительного замечания, дополнительное преимущество разделения вашего кода состоит в том, что вы можете поместить весь свой код в общий проект. Затем вы можете создать библиотеку классов для каждого порта, который вы можете сделать, скажем, один на прямом .net 4.6, а другой на .net core 5 и ссылку в вашем общем проекте. Пока ваш код совместим с обоими, он будет собираться, и у вас не будет дублированных файлов кода.