¿Existe una estructura recomendada, sugerida o convencional para proyectos .NET y/o ASP.NET?

Question

Estoy pensando en comenzar a trabajar en un proyecto .NET o ASP.NET a gran escala (aún no lo he decidido, pero es probable que, con el tiempo, se pueda acceder desde una aplicación de escritorio escrita en .NET así como una aplicación web ASP.NET). Sin embargo, no estoy seguro de si existe una forma convencional de estructurar el proyecto.

El proyecto en sí es una herramienta de gestión de recursos/conocimiento que rastrea varias fuentes de conocimiento: personas, publicaciones (libros, revistas, revistas), recursos web, documentos digitales (incluyendo PDF, documentos Word, documentos ODF, MP3 y más) y otros como mejor me parezca. Por supuesto, debido a que es tan grande, quiero poder implementar y probar una sección a la vez, pero tenerlas integradas en un solo sistema.

Una vez que tengo una o dos secciones hechas y probadas, quiero lanzar esto como una herramienta de código abierto. Sin embargo, si otros van a trabajar en esto, quiero presentarles una estructura fácil de entender. Sin embargo, nunca he trabajado en un proyecto ASP.NET y no he tocado .NET desde que el framework 2.0 era nuevo. Estoy buscando cualquier convención que exista dentro de la comunidad .NET, así como cualquier convención general sobre cómo se puede estructurar un proyecto a gran escala para hacer que el diseño, desarrollo, prueba, uso y mantenimiento sean lo más fáciles e indoloros posible para cualquiera que use o trabaje en este proyecto.

EDIT 1: No solo estoy buscando patrones (como lo señaló Toran Billups), sino también estructuras de directorios, estructuras de proyectos (como en el proyecto VisualStudio) y estructuras de documentación.

Answer 1

Si está trabajando con la tecnología de formularios web y desea crear una aplicación de escritorio con la misma base de código, le sugiero que utilice el patrón Model View Presenter para separar la interfaz de usuario de la codificación comercial. Además de este enfoque, recomendaría crear una capa de servicio que maneje la lógica más allá de la clase Presenter (incluido el acceso a datos/lógica de negocios).

Descubrí que la creación de una biblioteca de clases para contener este código de UI agnóstico hace que sea muy fácil reutilizar este código. Esta arquitectura también se presta a una transición de servicio web simple si toma esa ruta porque sus entradas/salidas de servicio deberían ser las mismas en su biblioteca de clase que en un servicio web (WCF o ASMX)

Sugeriría this excelente artículo de MSDN por el gran JP Boodhoo. Sigo esta misma estructura y el gran beneficio es que mi interfaz de usuario no maneja mi línea de aplicaciones empresariales. También son mucho más fáciles de mantener y reutilizables. Puedo hacer que una aplicación de formularios web use la misma biblioteca de clases que usa mi aplicación WPF.

Answer 2

Para la distribución de árbol de código, por lo general hacer algo como esto:

projectname/ 
      /source/ 
      /source/projectname.sln 
      /source/DataAccess/ 
      /source/DataAccess/DataAccess.csproj 
      /database/schema/ 
      /database/schema/something.sql 
      /database/testdata/ 
      /database/refdata/ 
      /tools/ 
      /COTS/ 
      /COTS/vendorname/ 
      /COTS/vendorname/somelib.dll 
      /doc/ 
      /build/ 
      /installer/ 
      /projectname.build 

Así que el directorio de nivel superior Tiene fichero de construcción del proyecto. Esto puede ser hormiga, marca, etc. Usamos FinalBuilder. Luego tiene subdirectorios para cada fuente, base de datos, herramientas, COTS, documento, etc. Puede pensar en otros, pero estos son los obvios.

Normalmente incluyo una carpeta de compilación para organizar el resultado de una compilación. Aquí es donde su instalador busca sus archivos.

En la parte superior del árbol de fuentes está mi archivo de solución visual studio. Cada subproyecto tiene su propio subdirectorio que contiene su archivo de proyecto vs y todo lo demás. Me gusta tener las cosas encapsuladas en proyectos bastante pequeños, por lo que podría tener 10 proyectos en una solución, cada uno con su propio subdirectorio bajo la fuente.

Las secuencias de comandos de la base de datos pueden separarse como prefiera, pero intente mantener separadas la estructura y los datos.

Herramientas es para las cosas que necesita para construir este proyecto.

COTS es para cosas externas que usted compró o descargó de las que depende pero que no puede compilar usted mismo.