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

Question

Можно создать дубликат:
ASP.NET: Web Site or Web Application?

я заметил, что существует явная разница в том, что вы получаете, когда вы стреляете up Visual Studio 2008 и выберите «Новый проект» -> «Веб-приложение ASP.NET» вместо «Новый веб-сайт '->« Веб-сайт ASP.NET ». Например, если вы выберете «Проект», вы можете скомпилировать файл .dll, и каждая страница получит файл * .aspx.designer.cs codebehind.

1) Почему у нас есть эти два разных типа проекта?

2) Что вы предпочитаете?

3) Почему я должен выбирать один над другим?

4) В чем дело с файлами * .aspx.designer.cs?

Answer 1

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

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

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

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

• MSDN Article describing the differences
• Similar stackoverflow question

Answer 2

Они имеют разные цели.

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

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

Answer 3

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

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

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

4. Никакая идея

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

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

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

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

Answer 4

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

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

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

Pros

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

Cons

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

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

Pros

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

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

Против

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

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

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

Answer 5

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

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

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

Answer 6

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

Answer 7

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

Главное отличие сайта, некоторые файлы должны быть размещены в определенных каталогах (файлы кода должны быть размещены в каталоге «App_Code»), кроме того, это довольно просто.

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

Answer 8

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

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

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

Nich

Answer 9

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

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

Answer 10

The простых ответов являются следующим:

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

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

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

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

Introduction to Web Application Projects

Answer 11

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