Sitio web ASP.NET o aplicación web ASP.NET?


Answers

El sitio web es lo que implementa en un servidor web ASP.NET como IIS. Solo un montón de archivos y carpetas. No hay nada en un sitio web que lo vincule con Visual Studio (no hay ningún archivo de proyecto). La generación de código y la compilación de páginas web (como .aspx, .ascx, .master) se realiza dinámicamente en tiempo de ejecución , y el marco detecta los cambios en estos archivos y los vuelve a compilar automáticamente. Puede colocar el código que desea compartir entre páginas en la carpeta especial Código_aplicaciones, o puede precompilarlo y colocarlo en la carpeta Bin.

La aplicación web es un proyecto especial de Visual Studio. La principal diferencia con los sitios web es que, al construir el proyecto, todos los archivos de código se compilan en un solo ensamblaje, que se coloca en el directorio bin. No implementa archivos de código en el servidor web. En lugar de tener una carpeta especial para archivos de código compartido, puede colocarlos en cualquier lugar, tal como lo haría en la biblioteca de la clase. Debido a que las aplicaciones web contienen archivos que no deben implementarse, como los archivos de proyecto y de código, existe un comando de publicación en Visual Studio para generar un sitio web en una ubicación específica.

App_Code vs Bin

La implementación de archivos de código compartido generalmente es una mala idea, pero eso no significa que tenga que elegir la Aplicación web. Puede tener un sitio web que haga referencia a un proyecto de biblioteca de clase que contenga todo el código del sitio web. Las aplicaciones web son solo una forma conveniente de hacerlo.

Código detrás

Este tema es específico de los archivos .aspx y .ascx. Este tema es cada vez menos relevante en los nuevos frameworks de aplicaciones como ASP.NET MVC y ASP.NET Web Pages que no usan código detrás de los archivos.

Al tener todos los archivos de código compilados en un único ensamblaje, incluido el código detrás de los archivos de las páginas .aspx y los controles .ascx, en las aplicaciones web debe volver a compilar para cada pequeño cambio, y no puede realizar cambios en tiempo real. Esto puede ser un verdadero problema durante el desarrollo, ya que debe seguir reconstruyendo para ver los cambios, mientras que con los sitios web los cambios son detectados por el tiempo de ejecución y las páginas / controles se vuelven a compilar automáticamente.

Hacer que el tiempo de ejecución administre los ensamblados de código subyacente es menos trabajo para usted, ya que no tiene que preocuparse por darles a las páginas / controles nombres únicos u organizarlos en diferentes espacios de nombres.

No digo que implementar archivos de código siempre es una buena idea (especialmente no en el caso de archivos de códigos compartidos), pero los archivos de código subyacente solo deben contener código que realice tareas específicas de UI, manejadores de eventos cableados, etc. Su aplicación debe ser en capas para que el código importante siempre termine en la carpeta Bin. Si ese es el caso, la implementación de archivos de código subyacente no debe considerarse perjudicial.

Otra limitación de las aplicaciones web es que solo puede usar el idioma del proyecto. En los sitios web puede tener algunas páginas en C #, algunas en VB, etc. No necesita soporte especial de Visual Studio. Esa es la belleza de la extensibilidad del proveedor de compilación.

Además, en las aplicaciones web no obtienes detección de errores en páginas / controles ya que el compilador solo compila tu código detrás de las clases y no el código de marcado (en MVC puedes arreglar esto usando la opción MvcBuildViews), que se compila en tiempo de ejecución.

Estudio visual

Debido a que las aplicaciones web son proyectos de Visual Studio, usted obtiene algunas características que no están disponibles en los sitios web. Por ejemplo, puede usar eventos de compilación para realizar una variedad de tareas, por ejemplo, minimizar y / o combinar archivos Javascript.

Otra buena característica presentada en Visual Studio 2010 es la transformación Web.config . Esto tampoco está disponible en los sitios web. Ahora funciona con sitios web en VS 2013.

Crear una aplicación web es más rápido que construir un sitio web, especialmente para sitios grandes. Esto se debe principalmente a que las aplicaciones web no compilan el código de marcado. En MVC, si configura MvcBuildViews como verdadero, compilará el código de marcado y obtendrá la detección de errores, que es muy útil. El inconveniente es que cada vez que construyes la solución construye el sitio completo, que puede ser lento e ineficiente, especialmente si no estás editando el sitio. Me encuentro activando y desactivando MvcBuildViews (lo que requiere la descarga de un proyecto). Por otro lado, con sitios web puede elegir si desea construir el sitio como parte de la solución o no. Si elige no hacerlo, la creación de la solución es muy rápida, y siempre puede hacer clic en el nodo del sitio web y seleccionar Crear, si ha realizado cambios.

En un proyecto de aplicación web MVC, tiene comandos y diálogos adicionales para tareas comunes, como 'Agregar vista', 'Ir a vista', 'Agregar controlador', etc. Estos no están disponibles en un sitio web de MVC.

Si usa IIS Express como servidor de desarrollo, en Sitios web puede agregar directorios virtuales. Esta opción no está disponible en las aplicaciones web.

NuGet Package Restore no funciona en sitios web, debe instalar manualmente los paquetes enumerados en packages.config La restauración de paquetes ahora funciona con sitios web a partir de NuGet 2.7

Question

Cuando inicio un nuevo proyecto ASP.NET en Visual Studio, puedo crear una aplicación web ASP.NET o puedo crear un sitio web ASP.NET.

¿Cuál es la diferencia entre la aplicación web ASP.NET y el sitio web ASP.NET? ¿Por qué elegiría uno sobre otro?

¿La respuesta es diferente según la versión de Visual Studio que estoy usando?




Modelo de proyecto de aplicación web

  • Proporciona la misma semántica de proyecto web que los proyectos web de Visual Studio .NET. Tiene un archivo de proyecto (estructura basada en archivos de proyecto). Modelo de compilación: todo el código del proyecto se compila en un solo ensamblaje. Admite IIS y el servidor de desarrollo ASP.NET incorporado. Admite todas las características de Visual Studio 2005 (refactorización, genéricos, etc.) y de ASP.NET (páginas maestras, membresía e inicio de sesión, navegación del sitio, temas, etc.). El uso de las Extensiones de servidor de FrontPage (FPSE) ya no es un requisito.

Modelo de proyecto del sitio web

  • Sin archivo de proyecto (Basado en el sistema de archivos).
  • Nuevo modelo de compilación.
  • Compilación dinámica y trabajo en páginas sin crear todo el sitio en cada vista de página.
  • Admite IIS y el servidor de desarrollo ASP.NET incorporado.
  • Cada página tiene su propio ensamblaje.
  • Modelo de código defferent.



Una de las principales diferencias es que los sitios web se compilan dinámicamente y crean ensamblajes sobre la marcha. Las aplicaciones web se compilan en una gran asamblea.

La distinción entre los dos se ha eliminado en Visual Studio 2008.




Definitivamente aplicación web, único archivo DLL y fácil de mantener. Pero un sitio web es más flexible; puede editar el archivo aspx sobre la marcha.




Un "sitio web" tiene su código en un directorio especial App_Code y se compila en varios archivos DLL (ensamblados) en tiempo de ejecución. Una "aplicación web" se precompila en una sola DLL.




Las aplicaciones generalmente se compilan antes de la implementación cuando el sitio web hace uso del directorio app_code. Cuando algo cambie en la carpeta del código de la aplicación, el servidor volverá a compilar el código. Esto significa que puede agregar / cambiar el código con un sitio web sobre la marcha.

La ventaja de una aplicación es que no se vuelve a compilar y, por lo tanto, los tiempos de inicio serán más rápidos.




En Proyectos de aplicaciones web, Visual Studio necesita archivos .designer adicionales para páginas y controles de usuario. Los proyectos del sitio web no requieren esta sobrecarga. El marcado en sí se interpreta como el diseño.




Las aplicaciones web requieren más memoria, presumiblemente porque no tiene más remedio que compilar en un solo ensamblaje. Acabo de convertir un gran sitio heredado a una aplicación web y tengo problemas con la falta de memoria, tanto en tiempo de compilación con el

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

error y en tiempo de ejecución con este error:

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

Mi recomendación para convertir sitios más grandes en hardware antiguo con limitaciones de memoria es permitirte la opción de volver al modelo del sitio web. Incluso después de un éxito inicial, los problemas podrían aparecer más tarde.




Depende de lo que estás desarrollando.

Un sitio web orientado al contenido tendrá su contenido cambiando con frecuencia y un sitio web es mejor para eso.

Una aplicación tiende a tener sus datos almacenados en una base de datos y sus páginas y códigos cambian raramente. En este caso, es mejor tener una aplicación web donde el despliegue de ensamblajes esté mucho más controlado y tenga mejor soporte para las pruebas unitarias.




Esto puede sonar un poco obvio, pero creo que es algo que no se comprende bien porque Visual Studio 2005 solo se envió originalmente con el sitio web. Si su proyecto trata con un sitio web que es bastante limitado y no tiene mucha separación lógica o física, el sitio web está bien. Sin embargo, si se trata realmente de una aplicación web con diferentes módulos donde muchos usuarios agregan y actualizan datos, es mejor que estés con la aplicación web.

El mayor profesional del modelo de sitio web es que cualquier elemento de la sección app_code se compila dinámicamente. Puede realizar actualizaciones de archivos C sin una redistribución completa. Sin embargo, esto viene en un gran sacrificio. Muchas cosas pasan bajo las cubiertas que son difíciles de controlar. Los espacios de nombres son difíciles de controlar y el uso específico de DLL sale por la ventana de forma predeterminada para todo lo que se encuentra en app_code ya que todo se compila dinámicamente.

El modelo de aplicación web no tiene compilación dinámica, pero usted obtiene control sobre las cosas que he mencionado.

Si está desarrollando n-tier, le recomiendo el modelo de aplicación web. Si está haciendo un sitio web limitado o una implementación rápida y sucia, el modelo del sitio web puede tener ventajas.

Se puede encontrar un análisis más detallado en:




A menos que tenga una necesidad específica de un proyecto dinámicamente compilado, no use un proyecto de sitio web .

¿Por qué? Porque el proyecto del sitio web lo llevará por la pared cuando intente cambiar o entender su proyecto. Las características de búsqueda de tipado estático (por ejemplo, encontrar usos, refactor) en Visual Studio tomarán para siempre en cualquier proyecto de tamaño razonable. Para obtener más información, consulte la Pregunta de desbordamiento de pila lenta "Buscar todas las referencias" en Visual Studio .

Realmente no puedo entender por qué eliminaron las aplicaciones web en Visual Studio 2005 para el tipo de proyecto de sitio web que causa dolor, agota la cordura y aumenta la productividad.




Sitios web: no se creará ningún archivo de solución. Si queremos crear sitios web, no es necesario Visual Studio.

Aplicación web: se creará un archivo de solución. Si queremos crear una aplicación web deberíamos necesitar el visual studio. Creará un solo archivo .dll en la carpeta bin.




Links