¿Cuál es la mejor manera de estructurar un proyecto?[cerrado]

Question

Me preguntaba cómo debería estructurar mis proyectos.

Tenemos algunos proyectos que se (re)utilizan en otros proyectos.

Quiero decir, nuestro proyecto de datos y nuestro proyecto modelo se utilizan en uno o muchos otros proyectos.

Lo que realmente quiero saber es cómo estructurar este tipo de proyecto, ¿cuál es la mejor forma de nombrarlo?

En una aplicación estándar de 3 niveles, debería ser algo como:

1. DAL, capa de acceso a datos, datos...
2. Modelo, BusinessObject, BOL...
3. Interfaz de usuario, Ver, ...

¿Alguna otra idea?

En cada empresa en la que trabajo tienen una forma diferente de organizarlo, ¿hay alguna mejor que otra?¿Cuál usas y cuál prefieres y por qué?

¡Gracias!

Answer 1

Para la capa de datos, suelo utilizar:

Empresa.NombreProyecto.Datos (es decir.AdventureWorks.OrderManager.Data)

Para la capa empresarial prefiero algo como "ObjectModel" (he usado "Business" o "BusinessLogic" pero esta es el área donde los datos se juntan en objetos/clases, así que ¿por qué no nombrarlo así?).

Empresa.NombreProyecto.ModeloObjeto (es decir.AdventureWorks.OrderManager.ObjectModel)

Para la interfaz de usuario, me gusta la antigua "UI" o la "Presentación"...

Empresa.NombreProyecto.Presentación (es decir.AdventureWorks.OrderManager.Presentación)

Answer 2

Eso es más o menos lo que hago, excepto el ive consiguió un par de proyectos de biblioteca donde trato de poner todo mi código reutilizable. Entonces mi modelo y DAL se sientan en la parte superior de estas librerias, simplemente añadiendo detalles del proyecto a ellos

Answer 3

Medio utilizo arquitectura en capas como se recomienda en Microsoft Patterns & Practices Arquitectura de la aplicación de .NET: Diseño de Aplicaciones y Servicios . El documento describe las tecnologías de arquitectura y .NET para ponerlo en práctica.

Answer 4

La arquitectura de software depende del tipo de software para construir. Si desea hacer la programación del kernel otros principios se aplican en comparación con el desarrollo de aplicaciones haciendo. Sin embargo, otros principios se aplican cuando su van a hacer la simulación física, software de tiempo-previsión, software IDE o compiladores.

Asumo que quiere hacer Desarrollos aplicación. Bueno, entonces lo más probable que desee diseñar su software en todo el dominio que se va a reflejar. Pero incluso entonces hay un montón de opciones.

Para obtener una visión más clara en este gran tema, sugiero que lea Domain Driven Design de Eric Evans y Applying Domain-Driven Design and Patterns de Jimmmy Nilsson.

Answer 5

Actualmente estoy trabajando en aplicaciones web front-end que tiene una arquitectura de 3 niveles:

• Nivel de cliente (el navegador)
• de nivel de aplicación (servidor de aplicaciones Java EE, donde vivirá la aplicación)
• tier Backend (sistema principal y de legado aplicaciones, diversas bases de datos)

Tiene una arquitectura en capas, y las capas en el nivel de aplicación son:

• capa de presentación: genera la interfaz de usuario que será utilizado en la capa de cliente
• capa de aplicación: el equivalente de casos de uso, contiene la lógica de aplicación
• capa de servicios: los mapas de la lógica de dominio y datos de backend de nivel en un modelo de Java
capa
• Integración: se comunica con el nivel de backend y contiene pasarelas para JMS, correo electrónico, ... y DAOs y otras cosas

Esto es sólo un ejemplo de estructura de proyectos, y el resultado final dependerá del tipo de aplicación. Puede leer más en mi respuesta a esta pregunta en la división y la estrategia de nomenclatura para los paquetes.

Puede añadir / permuta / eliminar las capas como mejor le parezca. En una SOA, por ejemplo, puede capa una capa de servicio web en la parte superior de la capa de la capa de aplicación o servicio, por lo que la ESB (Enterprise Service Bus) puede conectarse a su aplicación o servicios. Si nada de esto sea imposible o muy difícil parece, no tiene una arquitectura y un diseño óptimo.

Cuando se piensa en la estructura de su proyecto y para permitir escenarios como la de arriba, algunas propiedades importantes de sus módulos y componentes que desea son:

• Testabilidad
• Reutilización
• mantenibilidad

Esto se puede conseguir mediante el diseño de bajo acoplamiento y alta cohesión. La elección de una arquitectura en capas mediante la agrupación de módulos por el nivel de funcionalidad / abstracción es un buen comienzo. Dentro de cada capa de la agrupación aún más por la funcionalidad de ayuda también. Dejar que cada capa más específico sólo dependerá de las interfaces de una capa más general reduce el acoplamiento también.