Разница между "Веб-сайтом" и "Проектом" в Visual Studio

Ответ 1

1) Модель "веб-сайта" была представлена ​​с помощью ASP.NET 2.0, модель "веб-приложения" была типом проекта исходной .net-структуры. Они оба имеют разные виды использования (см. Ниже).

2) Это зависит от контекста. Хорошим примером является то, что если вы продаете программный продукт, вы можете использовать проект "веб-приложение", потому что он, естественно, поддается чистому скомпилированному коду.

3) См. выше, личные предпочтения, характеристики обслуживания. Интересное, что "веб-сайт" позволяет вам сделать это, может вызвать у вас массу неприятностей - вносить произвольные изменения в файл кода (обычно файл *.cs или *.vb) в блокноте, пока работает веб-сайт.

4) Файл designer.cs используется для хранения автоматически сгенерированного кода. "Этот код был сгенерирован инструментом.

• Статья MSDN, описывающая различия
• fooobar.com/questions/85680/...

Ответ 2

У них разные цели.

Сайт - это сайт с контентом, который со временем может измениться, то есть сами страницы будут меняться. Фактического файла проекта нет, и сайт развертывается просто как набор файлов.

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

Ответ 3

Я не буду дублировать определение 2, так как это только что получило ответ.

Так зачем использовать один над другим?

Веб-сайт позволяет вам рассматривать его как PHP или классический сайт ASP, где вы можете вносить встроенные изменения, которые вступают в силу немедленно.

Доводы

• Вы можете сделать настройки на сайте прямо на веб-сервере.
• Развертывание выполняется так же просто, как копирование папки

против

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

Веб-приложение позволяет вам относиться к нему скорее как к настольному приложению - на вашем компьютере можно скомпилировать одно развертывание.

Доводы

• Четкое структурированное управление изменениями. Вы не можете случайно смешивать код из двух разных версий. Это может быть важно, когда задействовано 2 человека - один записывает код и один отвечает за размещение файлов на сервере.

• Поскольку вы скомпилируете его на своей машине, все будет проверяться синтаксисом в этой точке *

против

• Развертывание более активно, а только копирование папки с вашей машины разработки. Однако использование команды "Опубликовать" значительно упрощает процесс компиляции и компоновки файлов, которые должны быть скопированы на веб-сервер.

• Любые изменения должны быть выполнены на вашем компьютере, скомпилированы и совершенно новая версия, отправленная на веб-сервер *

* Файлы aspx/html проверяются только синтаксисом, если вы включите это в своих вариантах сборки. Также возможно редактировать эти файлы на сервере, если они не скомпилированы в ваш проект.

Ответ 4

3) Проекты WebApplication могут быть созданы MSBuild. WebSites нет (без большой настройки). Если вы используете TeamSystem с автоматическими сборками, то это путь.

Ответ 5

Простые ответы таковы:

• Новый веб-сайт - создает код за страницами, которые скомпилированы на сервере при запросе страницы.
• Новый веб-проект - создает предварительно скомпилированные страницы в одну или несколько сборок (весь сайт ровно) и развертывается на сервере.

Сценарий №1 - Если хакер получает ваши файлы с кодом, все пароли базы данных отображаются. Эти страницы компилируются в момент их запроса. Вы можете предварительно скомпилировать все в большую сборку. Если нет, на сервере больше нагрузки.

Сценарий №2 - если хакер получит ваши сборки, они будут запутаны. Обфусканные сборки сложнее взломать. Эти сборки предварительно скомпилированы, что снижает нагрузку на сервер.

Для получения дополнительной информации:

Введение в проекты веб-приложений

Ответ 6

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

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

Вы действительно сможете придумать этот материал, если вы пытаетесь разработать сложный динамический сайт, где вы динамически загружаете множество пользовательских элементов управления во время выполнения на основе контента. Затем различия становятся болезненными - поэтому большая часть нашего развития зашла на ASP 1.1, пока мы не смогли вернуться к той же модели позже.

Nich

Ответ 7

Сайты - это оригинальная версия .NET.NET для веб-разработчиков. По моему опыту они крайне проблематичны, поскольку отсутствуют определения проекта, которые они не могут использовать повторно, и имеют проблемы с модульным кодированием, имеют проблемы с интеграцией TeamSystem и пространством имен. Связывание "один-к-одному" с доменом и отсутствие реальной абстракции публикации создают проблемы с обслуживанием в строю.

Древний "классический" способ ASP! codebehind - серьезная проблема, потому что он снова нарушает повторное использование и тестирование кода, а часто цитируемые преимущества предоставления горячих исправлений - если они когда-либо призваны - на самом деле являются массивным сигналом о том, что у вас есть неудачный процесс разработки. Возможность исправления, конечно, лучше, чем неспособность, но это то, что вы никогда не хотите вызывать.

Вы могли бы сказать, что проблемы с моделью веб-сайта были достаточно большими, чтобы MS предоставила нам веб-приложения. Лично я бы никогда не использовал их ни для чего кроме демо-кода... на самом деле я бы даже этого не сделал.

Ответ 8

Говоря об опыте обоих: "Веб-сайты" используются там, где нет методологии тестирования, нет сервера CI и культуры, которая регулярно поощряет и исправляет "исправления" на определенные страницы. "Веб-приложения" являются стандартом де-факто, где соблюдаются надлежащие методологии программного обеспечения, и есть единичное тестирование (если не полное TDD) и CI-сервер с акцентом на запись чистого кода и поиск ошибок до того, как возникнет необходимость в "исправлении".

Ответ 9

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

• I - и мое рабочее место - предпочитают проект веб-сайта

• Нам нравится, что файлы веб-сайта являются файлами в файловой системе (их не нужно добавлять вручную)

• Не знаю

Вот две статьи, которые я нашел обо всех:

http://damieng.com/blog/2008/02/07/web-site-vs-web-application

http://www.dotnetspider.com/resources/1520-Difference-between-web-site-web-application.aspx

Примечание.. Многие проблемы с веб-сайтами были устранены с помощью проекта развертывания веб-сайтов.

Обновление: Исправлена ​​точка 1, первое веб-приложение было

Ответ 10

Если в вашей работе необходимо использовать функции языка oo (иерархии классов, пространства имен) или если вам нужно повторно использовать общий код между проектами (доступ к данным, класс libs и т.д.), тогда проект веб-приложения - единственный путь.

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

Ответ 11

Существует очень небольшая разница, и я настоятельно рекомендую использовать модель веб-сайта.

Основное отличие для веб-сайта: некоторые файлы должны быть размещены в определенных каталогах (файлы кода должны быть помещены в каталог "App_Code" ), кроме того, это довольно просто.

Если скомпилированный код для развертывания важен для вас, и вы хотите, чтобы одна DLL (напротив нескольких, которые создаются при обычной публикации для веб-сайта), тогда вы захотите получить это дополнение, on: http://msdn.microsoft.com/en-us/asp.net/aa336619.aspx