Transferencia de datos entre la capa empresarial y la capa de acceso a datos: ¿código incorrecto?

Question

Estoy usando el siguiente código dentro de la clase JCProperty para recuperar datos de un DAL:

Dim x As JCProperty
        x = JCPropertyDB.GetProperty(PropertyID)

        If Not x Is Nothing Then
            Me.PropertyID = x.PropertyID
            Me.AddressLine1 = x.AddressLine1
            Me.AddressLine2 = x.AddressLine2
            Me.AddressLine3 = x.AddressLine3
            Me.AddressCity = x.AddressCity
            Me.AddressCounty = x.AddressCounty
            Me.AddressPostcode = x.AddressPostcode
            Me.TelNo = x.TelNo
            Me.UpdatedOn = x.UpdatedOn
            Me.CreatedOn = x.CreatedOn
            Me.Description = x.Description
            Me.GUID = x.GUID
        End If

Esto funciona bien, pero requiere que el objeto DAL (JCPropertyDB) conozca el objeto comercial (JCProperty) y efectivamente creo y puebla el mismo objeto dos veces (una vez en el DAL para volver al BL y luego nuevamente dentro del BL objeto para rellenarse a sí mismo).

Me falta algo aquí, ¡sé que debe haber una mejor manera!

Efectivamente necesito asignar 'Me = x' que no está permitido. ¿Alguien puede enderezarme?

Answer 1

Personalmente, soy vago. Usualmente hago algo como:

class JCProperty : inherits JCPropertyDB
   {

   New()
      {
      MyBase.New()

      GetProperty(PropertyID)

      }
   }

Entonces básicamente has terminado, hasta que tengas alguna funcionalidad adicional en la clase JCProperty que deba suceder " en la parte superior " de la funcionalidad ya existente en JCPropertyDB. Luego anula los métodos JCPropertyDB para llamar al método base primero y luego agrega tu nueva funcionalidad.

Ron

Answer 2

Estás en las líneas correctas, pero te falta un punto ligeramente.

Normalmente, su capa de acceso a datos (DAL) devolvería objetos de transferencia de datos (DTO) de tu base de datos. Estos son objetos CLR simples (POCO) que no contienen lógica de negocios, simplemente propiedades más o menos asignadas a las tablas de la base de datos.

Entonces tendría un código que crea un Modelo de dominio a partir de estos DTO, denominado un Data Mapper . Las clases en el Modelo de dominio pueden tener nombres similares (es decir, CustomerDTO - > Customer) pero además de los datos, contendrán reglas de validación y posiblemente otra lógica de negocios.

Es este Modelo de Dominio el que luego usa en su capa empresarial, no los DTO reales. Esto significa que si cambia los DTO devueltos por el DAL (es decir, implementando una nueva herramienta ORM), solo tiene que modificar su Data Mapper siempre que el modelo de datos permanezca igual.

Recomiendo mirar Patrones de arquitectura de aplicaciones empresariales de Martin Fowler para patrones de acceso a datos.

Answer 3

No estoy seguro de si esto responderá a su pregunta, pero el punto importante es que el modelo de dominio es independiente de la pantalla y del almacenamiento. Esto a menudo se denota como separación de preocupaciones. La idea es conseguir acoplamientos sueltos y crear un sistema simple donde los objetos no tengan varias responsabilidades completamente diferentes.
Entonces, lo que haría es permitir que el DAL cree objetos comerciales directamente, pero asegúrese de no contaminar mis objetos comerciales con nada relacionado con el DAL. Del mismo modo, no quiero contaminarlos con elementos específicos de la interfaz de usuario como HTML. En mi opinión, está bien que tanto la capa empresarial, DAL y la capa UI tengan dependencias del modelo de dominio, sin embargo, no está bien tener dependencias del modelo de dominio y de estos otros componentes.
Para aflojar los acoplamientos, usar algo Spring o cualquier otro contenedor de inyección de dependencia junto con interfaces y cableado puede ayudarlo.
Al recrear el mismo objeto en cada capa, está violando el principio DRY (no se repita) e introduce el código de la placa de la caldera y aumenta la posibilidad de introducir un error en alguna parte.

Answer 4

Echa un vistazo: http://www.icemanind.com/layergen.aspx

Answer 5

He estado aceptando BO y enviando BO desde el DAL a través del patrón de puente y el modelo de proveedor. No puedo ver el punto de los DTO a menos que tuviera miedo de una gran serialización (por ejemplo, un servicio web o JSON). Mi enfoque ha sido abstraer la capa Data-Layer y Business a través de una interfaz y proporcionar una capa de datos anónimos alimentada al objeto comercial. Esto significa que puedo conectar cualquier capa de datos, implementar una interfaz que tenga métodos universales de carga y almacenamiento y que luego sea accesible a través de mi capa de dominio. No hay código DAL en el BL, simplemente una llamada a una capa de datos proporcionada y abstraída. Mi llamada a la capa de datos es administrada por un patrón de proveedor (sin referencia directa) y simplemente hago:

public class Person : IBusinessObject<Person>
{
   protected IDataLayer<T> dataLayer;

   Person Load() { this.dataLayer.Load(this); }

}

en la capa de datos que tengo ...

public class PersonMapper : IDataLayer<Person> 
{
    Person Load(Person person) {
    ...get DB stuff...map to person...decorate object...
       return person;
    }
}

Todavía no sé si esto es bueno, pero funciona bastante bien para mí. También me las arreglé para obtener una carga diferida para los objetos anidados utilizando la reflexión.