architecture - revista - ¿Mejores prácticas para configurar un proyecto "empresarial" en Visual Studio?
lecturas revista ethos gubernamental (7)
Me estoy preparando para el desarrollo de una aplicación de estilo empresarial para un pequeño negocio de 6 empleados (incluyéndome a mí mismo). Antes de preguntar por qué una empresa de 6 personas necesitaría una aplicación empresarial, tenemos mucho que hacer con mucha procesos y herramientas necesarios para simplificarlo). Como siempre, intento seguir las mejores prácticas para configurar el proyecto; Voy a utilizar .NET 3.5, con la base de datos en Windows Server 2003 / SQL Server 2005.
Mientras estoy desarrollando y probando la solución, ¿debería tener todo en mi proyecto principal? Lo que quiero decir es ... Visual Studio 2008 Professional le permite tener "proyectos de bases de datos", así como todos los otros tipos de proyectos. Para esta aplicación, voy a necesitar:
- Proyecto de base de datos que contiene los scripts de creación y prueba para el nuevo esquema de datos
- Proyectos C # que contienen el código / aplicación real:
- Sitio (s) web orientado al cliente que utiliza ASP.NET MVC
- Sistema de procesamiento de pedidos de back-end, probablemente basado en la web pero posiblemente un "cliente inteligente"
- Proyecto SSIS que contiene paquetes para ETL los datos de la aplicación "en vivo" proporcionados por nuestro proveedor (es) y migra sobre datos existentes de clientes y pedidos desde la base de datos heredada.
- Proyecto de informes para SQL Server Reporting Services
Básicamente, me pregunto si es una buena idea tener todo esto como parte de una solución masiva de Visual Studio (llamémoslo "EnterpriseSolution"), o si debería dividirlos y abordarlos por separado. La mayoría de los libros y sitios web que he analizado los incluyen a todos juntos, pero también suponen un equipo de desarrolladores, administradores de bases de datos, arquitectos y similares. En este caso, estoy todos ellos en uno solo. El proyecto de la base de datos y al menos algunos procesos de ETL deben realizarse y cargarse en producción antes de que se escriba el resto de la aplicación, ya que tenemos que cargar los productos del nuevo proveedor en un entorno en vivo (para empezar a venderlos).
Estoy un poco abrumado sobre cómo debería comenzar a estructurar esto, pero quiero llegar a un plan general antes de comenzar a establecer las cosas y comenzar a codificar.
¿Alguna sugerencia sobre cómo abordar un proyecto como este?
Definitivamente es una buena idea usar una solución con varios proyectos en ella. Si desea utilizar ASP.NET MVC, defina un proyecto C # para cada capa: MVC Web, capa de servicio, capa de acceso a datos y proyecto de prueba separado. Puede aprender de la aplicación de muestra Storefront de Rob Conery o de Oxite .
También puede intentar utilizar paquetes de orientación del grupo de patrones y prácticas:
En primer lugar, el Proyecto de Base de Datos es excelente, y recomiendo usarlo para su capa de datos.
Me separaría por proyecto, ya que tiene sentido, pero lo mantengo todo en la misma solución.
Lo que he hecho es crear soluciones separadas para cada pieza independiente del proyecto y luego comenzar a integrarlas en soluciones más complejas. De esta forma, podría cargar solo una parte de la aplicación para pruebas o depuración de unidades.
Por ejemplo, en una aplicación de varias capas, crearía una solución independiente para la capa de datos y un proyecto de prueba de unidad. Otra solución incluiría la capa de datos y la capa de objetos de negocios trabajando en conjunto con las pruebas unitarias. La solución completa incluiría los proyectos mencionados anteriormente más el proyecto de UI
De esta forma puedo cargar y probar por separado cada parte de mi aplicación.
Me gusta comenzar con una única solución hasta que sea tan grande que los tiempos de construcción sean notablemente lentos.
Cómo se hace esto realmente depende de cómo las diferentes partes del sistema se interconectarán entre sí. La forma más fácil es adoptar una arquitectura orientada a servicios. Entonces cada servicio puede tener una solución diferente y el frontend su propia solución.
Sin embargo, realmente le recomendaría que trabaje con una solución y que solo haga las cosas más complicadas cuando sea necesario. Es bueno poder construir todo con un solo clic.
Me pareció más conveniente mantener el código del lado del cliente y del lado del servidor en soluciones separadas. Esto supone que el servidor presenta una interfaz estable, como un servicio web o una interfaz WCF.
Con el tiempo las cosas crecen, puede usar más de una tecnología de cliente (Windows, web ...) y mantener estos clústeres de tecnología separados en sus propias soluciones simplifica las cosas.
Si está buscando una buena muestra de arquitectura, consulte el Northwind Starter Kit en CodePlex. Encontré esto al leer " Microsoft .Net: Aplicaciones de arquitectura para la empresa ", de Dino Esposito y Andrea Saltarello.
El Northwind Starter Kit es una aplicación de muestra producida por Managed Designs ( http://www.manageddesigns.it ) y pretende ser utilizada como un blueprint al diseñar e implementar una arquitectura de aplicación en capas .NET. La aplicación utiliza la base de datos Northwind estándar, como se incluye en Microsoft SQL Server y Microsoft Access: no se requieren modificaciones en el esquema de la base de datos para instalar y ejecutar el kit de inicio.
Estoy de acuerdo con @Chris Ballance en que incluir un Proyecto de base de datos puede ser muy útil. Pero tenga en cuenta que el proyecto DB puede parecer un poco complicado, ya que sincroniza el proyecto y las estructuras de base de datos de referencia.
+ tom
No hay ninguna razón para que la aplicación no pueda ser todo en uno, si necesita elementos de fragmentación podría hacerlo más adelante, siempre y cuando mantenga sus objetos ligeramente acoplados.
El único aspecto agradable de tener proyectos separados es que puede compilar una sección con éxito mientras tiene otras secciones incompletas, simplemente descargándolas.
Yo recomendaría crear una "Solución en blanco" para iniciar que sería un archivo * .sln (Say EnterpriseSolution.sln) que se ubicaría en una carpeta llamada EneterpriseSolution. Se puede crear una solución en blanco desde "Otros tipos". Luego agregaría las partes adicionales que describió como proyectos separados, cada una dentro de su propia carpeta debajo de la carpeta "EnterpriseSolution".
Por ejemplo, cada uno de los sitios web de sus clientes tendrá cada uno su propia carpeta de proyectos. Parece que tendrá más de un sitio web, por lo que deberá asegurarse de configurar diferentes "puertos" para que se ejecute cada uno si utiliza un contenedor de solución. Sin embargo, también puede crear diferentes "envoltorios" de soluciones (como una solución en blanco para comenzar y luego referenciar los proyectos que desee) para incluir cada sitio web específicamente en la estructura de su carpeta para que pueda enfocarse en una parte de su solución empresarial. Pero físicamente sabrá dónde está todo y cómo está organizado.
De esta forma, cuando mires la carpeta Enterprise Solution a través del explorador de Windows, lo único que verás serán los archivos de tu solución y las carpetas de tus proyectos.
Gracias y buena suerte con tu proyecto.