asp.net - una - Diferencia entre ''Sitio web'' y ''Proyecto'' en Visual Studio

paginas web asp.net ejemplos (11)

Posible duplicado:
ASP.NET: ¿Sitio web o aplicación web?

He notado que hay claramente una diferencia en lo que obtienes cuando activas Visual Studio 2008 y eliges '' Nuevo proyecto '' -> ''Aplicación web ASP.NET'' en lugar de '' Nuevo sitio web '' -> ''Sitio web ASP.NET ''. Por ejemplo, si elige ''Proyecto'', entonces puede compilar a .dll y cada página obtiene un archivo de código subyacente * .aspx.designer.cs.

1) ¿Por qué tenemos estos dos tipos de proyectos diferentes?

2) ¿Cuál prefieres?

3) ¿Por qué elegiría uno sobre el otro?

4) ¿Cuál es el problema con los archivos * .aspx.designer.cs?

Al principio había un proyecto de aplicación web (se comportaba de manera similar al proyecto actual del sitio web). Lo cambiaron para reflejar lo que algunos usuarios solicitaron. Sin embargo, la gente quería recuperar la funcionalidad anterior, por lo que volvieron a introducir el proyecto del sitio web que se comporta como el proyecto original de la aplicación web.
Yo, y mi lugar de trabajo, prefiero el proyecto del sitio web
Nos gusta que los archivos del sitio web sean los archivos en el sistema de archivos (no es necesario agregarlos manualmente)
Ni idea

Aquí hay dos artículos que encontré sobre ambos:

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

Nota: Muchos de los problemas con los sitios web se han resuelto con el proyecto de implementación web

Actualización: corrigió el punto 1, la aplicación web estaba allí primero

1) El modelo del "sitio web" se introdujo con ASP.NET 2.0, el modelo de "aplicación web" era el tipo de proyecto del .NET framework original. Ambos tienen diferentes usos (ver abajo).

2) Depende del contexto. Un buen ejemplo es que si está vendiendo un producto de software, es posible que desee utilizar un proyecto de "aplicación web" porque, naturalmente, se presta a un código compilado limpiamente.

3) Ver arriba, preferencia personal, características de mantenimiento. Una cosa interesante que un ''sitio web'' le permite hacer y que le puede ocasionar muchos problemas es realizar cambios arbitrarios en el archivo de código subyacente (generalmente un * .cs o * .vb) en el bloc de notas mientras se está ejecutando el sitio web.

4) El archivo designer.cs se usa para almacenar el código generado automáticamente. "Este código fue generado por una herramienta".

3) Los proyectos de aplicación web son edificables por MSBuild. Los sitios web no son (sin muchos ajustes). Si usa TeamSystem con compilaciones automáticas, este es el camino a seguir.

Ellos tienen diferentes propósitos.

Un sitio web es un sitio con contenido que probablemente cambiará con el tiempo, es decir, las páginas cambiarán. No hay un archivo de proyecto real y el sitio se implementa simplemente como un conjunto de archivos.

Una aplicación es un sitio donde el contenido es solo la aplicación, la parte dinámica estará principalmente en una tienda persistente como una base de datos. Tendrá una lógica más compleja ya que es probable que represente un conjunto de formularios para la entrada de datos tanto como un medio para examinar el contenido. Tiene un archivo de proyecto para controlar más estrictamente su configuración y su código implementado como un dll compilado.

Hablando de la experiencia con ambos: "sitios web" se utilizan cuando no hay una metodología de prueba implementada, ningún servidor de CI, y una cultura que alienta y promueve "revisiones" a páginas específicas con regularidad. Las "aplicaciones web" son el estándar de facto donde se siguen metodologías de software adecuadas y hay pruebas unitarias (si no completas TDD) y un servidor de CI con un enfoque en escribir código limpio y encontrar errores antes de que surja la necesidad de una "revisión".

La mayor diferencia que nadie ha mencionado realmente (excepto tocado por Annakata) es que con el modelo en el que todo se compila en una única DLL, usted tiene control total sobre las clases que genera su aplicación. Usted sabe dónde están y siempre puede hacer referencia a ellos desde cualquier otro lugar en la aplicación.

Con el modelo de una sola página, no puedes hacer esto. Tienes que resolverlo creando clases "stub" en el directorio de AppCode, y heredando esas en tus páginas, pero incluso eso no es lo ideal, y agrega complejidad.

Si realmente intenta desarrollar un sitio dinámico intrincado, carga dinámicamente muchos controles de usuario en tiempo de ejecución basados en el contenido. Entonces, las diferencias son dolorosamente claras, por lo tanto, gran parte de nuestro desarrollo se estancó en ASP 1.1 hasta que pudiéramos volver al mismo modelo más adelante.

Nich

Las respuestas simples son las siguientes:

Nuevo sitio web: crea el código detrás de las páginas compiladas en el servidor cuando se solicita la página.
Nuevo proyecto web: crea páginas compiladas previamente en uno o más ensambles (incluso el sitio completo) y se implementa en el servidor.

Escenario n.º 1: si un pirata informático obtiene sus archivos de código subyacente, cualquier contraseña de base de datos quedará expuesta. Estas páginas están compiladas en el momento en que se solicitan. Puede optar por precompilar todo en un ensamblaje grande. Si no, hay más carga en el servidor.

Escenario n.º 2: si un pirata informático obtiene sus ensamblajes, se ofuscarán. Las asambleas ofuscadas son más difíciles de descifrar. Estos ensamblajes están precompilados, lo que reduce la carga en el servidor.

Para más información:

Introducción a proyectos de aplicaciones web

Los sitios son la forma original de .NET 2003 de hacer desarrollo web. En mi experiencia, son extremadamente problemáticos ya que carecen de una definición de proyecto que no puedan ser reutilizados y tienen problemas con la codificación modular, tienen problemas con la integración de TeamSystem y el espacio de nombres. El enlace de uno a uno con un dominio y la falta de abstracción de publicación real crea problemas de mantenimiento en el futuro.

La antigua forma "ASP" clásica de! Codebehind es un problema grave porque vuelve a perjudicar la reutilización y prueba del código, y los beneficios a menudo citados de permitir correcciones instantáneas (si alguna vez se solicita) son en realidad una señal masiva de que tiene un proceso de desarrollo fallido . La capacidad de corregir en caliente es, por supuesto, mejor que no poder hacerlo, pero es algo que nunca querrá invocar.

Se podría decir que los problemas con el modelo de sitio web fueron lo suficientemente buenos como para que MS nos diera aplicaciones web. Personalmente, nunca los usaría para nada más allá del código de demostración ... en realidad, ni siquiera lo haría.

No voy a duplicar la definición de 2, ya que eso acaba de ser respondido.

Entonces, ¿por qué usar uno sobre el otro?

El sitio web le permite tratarlo como un sitio ASP PHP o clásico, donde puede realizar cambios en línea que tienen efecto de inmediato.

Pros

Puede realizar ajustes en el sitio directamente en el servidor web
Desplegar es tan simple como copiar la carpeta

Contras

Si no realiza los cambios correctamente en el sitio en vivo, puede entrar en problemas de administración de cambios, donde se olvida de mantener todos sus archivos sincronizados.
Puede obtener los errores de sintaxis en tiempo de ejecución que se muestran a sus usuarios finales, ya que la única forma de comprobar es ejecutar manualmente cada página

La aplicación web le permite tratarla de manera más parecida a como lo haría con una aplicación de escritorio; hay una implementable que se compila en su máquina.

Pros

Gestión de cambios clara y estructurada. No se puede mezclar accidentalmente el código de dos versiones diferentes. Esto puede ser importante cuando hay dos personas involucradas: una que escribe el código y la otra responsable de colocar los archivos en el servidor.
Como lo compila en su máquina, todo se comprueba sintaxis en ese punto *

Contras

La implementación es un poco más complicada que copiar la carpeta de su máquina de desarrollo. Sin embargo, el uso del comando "Publicar" simplifica enormemente el proceso de compilación y recopilación de los archivos que se deben copiar en el servidor web.
Cualquier cambio debe hacerse en su máquina, compilarse y enviarse una nueva versión al servidor web *

* Los archivos aspx / html solo son sintaxis marcados si activa esto en sus opciones de compilación. También es posible editar estos archivos en el servidor a menos que estén compilados en su proyecto.

Si su trabajo necesita aprovechar las características del idioma (jerarquías de clase, espacios de nombres) o si necesita volver a usar código común entre proyectos (acceso a datos, bibliotecas de clases, etc.), entonces el proyecto de aplicación web es el único camino a seguir.

El proyecto del sitio web (la pista está en el nombre) solo es realmente bueno para los sitios ''brochureware'' no complejos (donde las páginas consisten en contenido estático) en oposición a las aplicaciones web.

Hay muy poca diferencia, y recomendaría mucho usar el modelo del sitio web.

La principal diferencia es para un sitio web, algunos archivos deben colocarse en ciertos directorios (los archivos de código deben colocarse en el directorio ''Código_Ap_''), además de eso, es bastante sencillo.

Si tener código compilado para la implementación es importante para usted, y desea una sola DLL (a diferencia de las varias que se crean cuando realiza una publicación normal para un sitio web), entonces querrá obtener este complemento: http://msdn.microsoft.com/en-us/asp.net/aa336619.aspx