GUI, BLL, DAL Organización en un proyecto

Estoy leyendo sobre las capas de aplicación y quiero usar este diseño en mi próximo proyecto (c #, .Net). Algunas preguntas:

1. ¿La separación de capas se realiza a través de espacios de nombres? Project.BLL.Whatever, Project.DAL.Whatever

2. ¿Es más apropiado separar por capas, luego componentes (Project.BLL.Component1), o por componentes, luego capas (Project.Component1.BLL)

3. Para mi DAL, ¿esta capa está más organizada usando diferentes clases? Si todas las llamadas a la base de datos se colocan en una sola clase, no hay organización. ¿Sería mejor dividirlos con diferentes clases o espacios de nombres?

4. ¿Son las clases DAL típicamente estáticas? Parece engorroso instanciar un objeto DAL antes de llamar a uno de sus métodos cada vez.

Se agradecería cualquier otro consejo para hacer las cosas correctamente con estas capas.

1. Si. Y también asambleas.
2. Me separaría por capas, luego por componentes.
3. Si. Hay diferentes enfoques para esto, pero tendría un IDatabaseService (abstrayendo las diversas formas en que se llama a la base de datos; esto puede ser casi una asignación directa de ExecuteScalar / ExecuteNonQuery / ExecuteReader), y luego varias clases de acceso a datos que partición por tipo de datos. Por ejemplo, podría tener una clase UserDataAccess que tendría métodos CRUD simples que crean / modifican / eliminan objetos de usuario. Otro enfoque sería tener un objeto Usuario que tenga el CRUD incorporado.

4. No. Eso hace que sea mucho más difícil hacer una prueba unitaria. Debe usar la inyección de dependencia para pasar dependencias al constructor de cada clase de acceso a datos (como un IDatabaseService). Luego pasaría los objetos de acceso a datos a los objetos comerciales, de esta manera:

   BusinessObject businessObject = new BusinessObject (nuevo DataAccessObject (nuevo DatabaseService ())); businessObject.PerformOperation ();

Cada objeto comercial puede necesitar múltiples objetos de acceso a datos. Su código GUI también usaría uno o más objetos comerciales. Es posible que algunos objetos comerciales no necesiten ningún objeto de acceso a datos, pero nunca deben usar el IDatabaseService directamente.

Para las preguntas 1 y 2, vaya con las respuestas de Matthew.

He pasado mucho tiempo tratando de descubrir la mejor manera de estructurar el DAL de las aplicaciones de escritorio. Y la mejor manera realmente depende de las necesidades de la aplicación. En una de mis aplicaciones, tomé el camino de tener una clase DA para cada tabla de base de datos, que se registró con una clase DataProvider central (es decir, singleton) y manejó el CRUD. Cada clase de DA podría decidir si quería almacenar en caché todos los datos de la tabla en RAM o no (¡rendimiento!) Y / o si necesitaba tener la capacidad de activar actualizaciones automáticas de clientes en otros clientes que se ejecutan en otras computadoras (piense en multiusuario concurrencia). Esto hace que sea muy fácil agregar nuevas clases DAL, ya que todo lo que tienen que hacer es ajustarse a la interfaz de registro.

No todos los DAL necesitan este tipo de funcionalidad, pero aprendí que el enfoque en sí mismo (es decir, proveedor de datos singleton y clases DAL simples con registro estático) me hizo la vida mucho más fácil cuando comencé a agregar nuevas clases.

Definitivamente no recomendaría construir el CRUD en clases de nivel superior, a menos que sea una aplicación muy simple. El DAL es una abstracción del almacenamiento de datos. Si decide cambiar su almacenamiento de datos en algún momento en el futuro (incluso si es solo para usar MySQL en lugar de MS SQL), estará muy agradecido por eso. Además: los objetos BLL deben estructurarse según sus relaciones de lógica de negocios. Los objetos DAL están estructurados por los tipos de contenedores de almacenamiento que representan. Las diferencias pueden ser dramáticas.

No NO hacer su clases DAL estática. Lo que gana en la velocidad de codificación lo perderá muchas veces en capacidad de prueba y flexibilidad.