.net, C# Interfaz entre Business Logic y DAL

Question

Estoy trabajando en una pequeña aplicación desde el principio y la uso para tratar de enseñarme conceptos de arquitectura y diseño. Es una .NET 3.5, aplicación WPF, y estoy usando Sql Compact Edition como mi almacén de datos.

Estoy trabajando en la capa de lógica de negocios, y acabo de comenzar a escribir el DAL. Solo estoy usando SqlCeComamnds para enviar consultas simples y SqlCeResultSet para obtener los resultados. Estoy empezando a diseñar mis métodos Insertar y Actualizar, y este es el problema: no sé cuál es la mejor manera de obtener los datos necesarios del BLL en el DAL. ¿Paso en una colección genérica? ¿Tengo una lista de parámetros masiva con todos los datos para la base de datos? ¿Simplemente paso el objeto comercial real (atando así mi DAL a las cosas conrete en el BLL?).

Pensé en usar interfaces, simplemente pasando IBusinessObjectA al DAL, lo que proporciona la simplicidad que estoy buscando sin atarme demasiado a las implementaciones actuales. ¿Qué piensan ustedes?

Answer 1

Si estuviera en su posición, probablemente usaría LINQ to SQL para definir mi capa de acceso a datos; le ahorrará mucho trabajo manteniendo todas las cosas de SqlCeFooBar y le dará un diseñador (de tipo) para mantener su base de datos que de otra manera carecería, utilizando SQL CE.

Entonces, en ese caso, probablemente uniría la capa de lógica de negocios bastante a las entidades expuestas por la capa L2S. La justificación es que las entidades son los objetos comerciales, aunque carecen de cualquier servicio.

Probablemente no dejaría que las entidades subieran tanto en la jerarquía como la UI. En ese nivel, tiene mucho más sentido usar un modelo específico para la vista, especialmente dado que está usando WPF.

Por supuesto, todo esto depende del tamaño y la complejidad de su aplicación. Supongo que se trata de una aplicación de escala bastante pequeña (¿usuario único?) Dado que está utilizando SQL CE.

Answer 2

Creo que está bien pasar el objeto comercial a la capa de acceso a datos. Creo que el trabajo del BLL es sólo para trabajar con sus objetos, para comprobar si se han respetado todas las reglas, de lo que se pueden guardar, por quién, en qué campos, tiempo, etc.

Una vez que ha hecho que debería Pasarlo al DAL, y creo que es trabajo de TI descubrir cómo convertir lo que se convirtió en algo que puede persistir, pero no comprobará qué es lo que persiste o lo que lee, o quién lo hará, simplemente lo hará. Esto podría ser directo, a la linq, pero si tus mdoels lógicos no coinciden con tu modelo de datos 1: 1, entonces el DAL debería hacer toda la conversión.

Acerca de vincular su DAL a las cosas en el BLL, creo que debe preocuparse por el contrario, atando su BLL a su DAL. Usaría una interfaz para representar tu DAL (como en el IRepository) de esa manera puedes hacer que tu BLL llame a cualquier tipo de mecanismo de persistencia simplemente cambiando el tipo de IRepository que está usando (puntos extra si usas IoC: P). Las clases concretas que implementan el IRepository se vincularán a los objetos de negocio, pero tienen que saber qué es lo que están guardando, ¿no? mientras que el BLL NO tiene que saber qué está haciendo el ahorro.

Answer 3

No creo que haya una respuesta simple a sus preguntas porque hay muchas opciones según las circunstancias. Me ha resultado útil leer los dos libros a continuación para ayudarme a comprender mejor los problemas que describes.

• MS .NET: Arquitectura de Aplicaciones para la Empresa (Esposito, Saltarello)
• MS Guía de Arquitectura de la aplicación, 2ª edición.

El segundo libro está disponible en línea. Mire here.

Answer 4

Pasar objeto comercial en el DAL es el método más simple y rápido. Funciona en proyectos pequeños, pero tiene las mismas desventajas:

1) Business Objects forma parte de la capa BLL, y si pasa objetos en BLL, DAL pasa a ser dependiente de BLL. la capa baja sabe sobre la superior, esto contradice la idea de capas en absoluto.

2) Business Object son usualmente muy complejos para guardarlo directamente en BD. En este caso, es mejor introducir una capa intermedia nueva de "Mappers".

Para superar todos estos problemas, usualmente hago interfaz a DAL independiente de Business Objects. En su lugar, utilizo las clases "Fila": representación de un registro en la base de datos o XML. En .NET 3.Se pueden usar 5 clases autogeneradas de linqtosql para este propósito.