Веб-сайт ASP.NET или веб-приложение ASP.NET?


Answers

Веб-сайт - это то, что вы развертываете на веб-сервере ASP.NET, таком как IIS. Просто куча файлов и папок. На веб-сайте нет ничего связанного с Visual Studio (нет файла проекта). Генерация кода и компиляция веб-страниц (например, .aspx, .ascx, .master) выполняются динамически во время выполнения , а изменения этих файлов обнаруживаются каркасом и автоматически перекомпилируются. Вы можете поместить код, который хотите разделить между страницами в специальной папке App_Code, или вы можете предварительно скомпилировать его и поместить сборку в папку Bin.

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

App_Code против Bin

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

CodeBehind

Этот раздел посвящен файлам .aspx и .ascx. Эта тема становится все более актуальной в новых инфраструктурах приложений, таких как ASP.NET MVC и веб-страницы ASP.NET, которые не используют файлы кода.

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

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

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

Еще одним ограничением веб-приложений является то, что вы можете использовать только язык проекта. На веб-сайтах вы можете иметь некоторые страницы на C #, некоторые в VB и т. Д. Нет необходимости в специальной поддержке Visual Studio. Это красота расширяемости поставщика.

Кроме того, в веб-приложениях вы не обнаруживаете ошибки в страницах / элемента управления, поскольку компилятор только компилирует ваши классы кода, а не код разметки (в MVC вы можете исправить это, используя параметр MvcBuildViews), который компилируется во время выполнения.

Visual Studio

Поскольку веб-приложения представляют собой проекты Visual Studio, вы получаете некоторые функции, недоступные на веб-сайтах. Например, вы можете использовать события сборки для выполнения множества задач, например, для минимизации и / или объединения файлов Javascript.

Еще одна приятная функция, представленная в Visual Studio 2010, - это преобразование Web.config . Это также не доступно на веб-сайтах. Теперь работает с веб-сайтами в VS 2013.

Создание веб-приложения происходит быстрее, чем создание веб-сайта, особенно для крупных сайтов. Это связано главным образом с тем, что веб-приложения не компилируют код разметки. В MVC, если вы установите MvcBuildViews в true, тогда он компилирует код разметки, и вы получаете обнаружение ошибок, что очень полезно. Нижняя сторона заключается в том, что каждый раз, когда вы строите решение, он строит полный сайт, который может быть медленным и неэффективным, особенно если вы не редактируете сайт. Я нахожу, что включаю и выключаю MvcBuildViews (что требует выгрузки проекта). С другой стороны, с помощью веб-сайтов вы можете выбрать, хотите ли вы построить сайт как часть решения или нет. Если вы решите не делать этого, то создание решения происходит очень быстро, и вы всегда можете щелкнуть узел веб-узла и выбрать «Сборка», если вы внесли изменения.

В проекте MVC Web Application у вас есть дополнительные команды и диалоги для общих задач, такие как «Добавить вид», «Перейти к представлению», «Добавить контроллер» и т. Д. Они недоступны на веб-сайте MVC.

Если вы используете IIS Express в качестве сервера разработки, на веб-сайтах вы можете добавлять виртуальные каталоги. Этот параметр недоступен в веб-приложениях.

Восстановление пакета NuGet не работает на веб-сайтах, вам необходимо вручную установить пакеты, перечисленные на packages.config Пакет восстановления теперь работает с веб-сайтами, начиная с NuGet 2.7

Question

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

В чем разница между веб-приложением ASP.NET и веб-сайтом ASP.NET? Почему я должен выбирать один над другим?

Является ли ответ разным в зависимости от того, какую версию Visual Studio я использую?




Модель проекта веб-приложения

  • Предоставляет семантику того же Web-проекта, что и веб-проекты Visual Studio .NET. Имеет файл проекта (структура, основанная на файлах проекта). Build model - весь код проекта скомпилирован в единую сборку. Поддерживает как IIS, так и встроенный сервер разработки ASP.NET. Поддерживает все функции Visual Studio 2005 (рефакторинг, дженерики и т. Д.) И ASP.NET (мастер-страницы, членство и логин, навигацию по сайту, темы и т. Д.). Использование FrontPage Server Extensions (FPSE) больше не является обязательным требованием.

Модель проекта веб-сайта

  • Нет файла проекта (на основе файловой системы).
  • Новая модель компиляции.
  • Динамическая компиляция и работа на страницах без создания всего сайта на каждом просмотре страницы.
  • Поддерживает как IIS, так и встроенный сервер разработки ASP.NET.
  • У каждой страницы есть своя сборка.
  • Модель дефферентного кода.



Веб-сайты. Файл решения не будет создан. Если мы хотим создавать веб-сайты, вам не нужна визуальная студия.

Веб-приложение. Будет создан файл решения. Если мы хотим создать веб-приложение, вам нужна визуальная студия. Он создаст один .dll файл в папке bin.




«Веб-сайт» имеет свой код в специальном каталоге App_Code и скомпилирован в несколько DLL (сборок) во время выполнения. «Веб-приложение» предварительно скомпилировано в одну DLL.




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

Unexpected error writing metadata to file '' -- 
Not enough storage is available to complete this operation. 

ошибка и во время выполнения с этой ошибкой:

Exception information: 
    Exception type: HttpException 
    Exception message: Exception of type 'System.OutOfMemoryException' was thrown.
   at System.Web.Compilation.BuildManager.ReportTopLevelCompilationException()

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




Это зависит от того, что вы разрабатываете.

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

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




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

Различие между ними было устранено в Visual Studio 2008.




Это может показаться немного очевидным, но я думаю, что это то, что неправильно понимается, потому что Visual Studio 2005 только первоначально отправляется на веб-сайт. Если ваш проект имеет дело с сайтом, который является довольно ограниченным и не имеет большого логического или физического разделения, веб-сайт в порядке. Однако, если это действительно веб-приложение с различными модулями, где многие пользователи добавляют и обновляют данные, вам лучше работать с веб-приложением.

Самый большой профи модели веб-сайта заключается в том, что все в разделе app_code динамически компилируется. Вы можете делать обновления файлов C # без полного перераспределения. Однако это приносит огромную жертву. Много вещей происходит под крышками, которые трудно контролировать. Пространства имен трудно контролировать, а использование определенной библиотеки DLL по умолчанию используется для всего, что находится под app_code поскольку все динамически компилируется.

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

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

Более подробный анализ можно найти в:




Если у вас нет конкретной потребности в динамически скомпилированном проекте, не используйте проект веб-сайта .

Зачем? Поскольку проект веб-сайта приведет вас к стене, когда вы пытаетесь изменить или понять свой проект. Элементы поиска статической типизации (например, поиск использования, рефакторинг) в Visual Studio будут выполняться навсегда в любом проекте с разумным размером. Для получения дополнительной информации см. Вопрос « Переполнение стека». Медленно «Найти все ссылки» в Visual Studio .

Я действительно не понимаю, почему они отбросили веб-приложения в Visual Studio 2005 для создания проекта, основанного на причинении боли, безумности, производительности проекта карбункула производительности.




Обычно приложения скомпилируются перед развертыванием, когда сайт использует каталог app_code. Когда что-либо изменяется в папке с кодом приложения, сервер будет перекомпилировать код. Это означает, что вы можете добавлять / изменять код с веб-сайта «на лету».

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




Определенно веб-приложение, один DLL-файл и прост в обслуживании. Но сайт более гибкий; вы можете редактировать файл aspx на ходу.




В проектах веб-приложений Visual Studio нуждается в дополнительных файлах .designer для страниц и пользовательских элементов управления. Проекты веб-сайта не требуют этих накладных расходов. Сама разметка интерпретируется как дизайн.