Patrón de carga de entidad empresarial

Question

El proyecto en el que estoy trabajando está usando una arquitectura de n niveles. Nuestras capas son las siguientes:

• acceso a datos
• lógica de negocios
• Entidades comerciales
• Presentación

La lógica de negocios llama a la capa de acceso a los datos, y la capa de presentación baja a la capa de la lógica de negocios, y todas las entidades de negocios hacen referencia a ellas.

Nuestras entidades comerciales esencialmente coinciden con nuestro modelo de datos 1-1. Para cada mesa, tenemos una clase. Inicialmente, cuando se diseñó el marco, no se tuvo en cuenta la gestión de los detalles maestros o las relaciones entre padres e hijos. Por lo tanto, todas las entidades de lógica de negocio, acceso a datos y negocio solo hicieron referencia a una única tabla en la base de datos. Una vez que comenzamos a desarrollar la aplicación, rápidamente se hizo evidente que no tener estas relaciones en nuestro modelo de objetos nos estaba perjudicando gravemente.

Todas sus capas (incluida la base de datos) se generan a partir de una base de datos de metadatos interna que utilizamos para impulsar nuestro generador de código propio.

La pregunta es cuál es la mejor manera de cargar o cargar de forma perezosa las relaciones en nuestras entidades. Por ejemplo, digamos que tenemos una clase de persona que tiene una relación maestro-hijo con una tabla de direcciones. Esto aparece en la entidad comercial como una propiedad de colección de Direcciones en el objeto Persona. Si tenemos una relación de uno a uno, esto se mostrará como una propiedad de entidad única. ¿Cuál es el mejor enfoque para rellenar y guardar los objetos de relación? Nuestras entidades comerciales no tienen conocimiento de la capa de lógica empresarial, por lo que no se puede hacer internamente cuando se llama a la propiedad.

Estoy seguro de que hay algún tipo de patrón estándar por ahí para hacer esto. ¿Alguna sugerencia?

Además, una advertencia es que la capa DataAcess utiliza la reflexión para construir nuestras entidades. Los procedimientos almacenados devuelven una marca de resultado basada en una tabla y, mediante la reflexión, rellenamos nuestro objeto de negocio al hacer coincidir los nombres de las propiedades con los nombres de las columnas. Así que hacer uniones sería difícil.

Answer 1

Recomiendo encarecidamente consultar el libro Patrones de arquitectura empresarial de Fowler. Hay algunos enfoques diferentes para resolver este tipo de problema que él describe muy bien, incluidas las relaciones entre entidades.

Uno de los elementos más convincentes sería el patrón de Unidad de trabajo, que es básicamente un recopilador, que observa las acciones realizadas en sus entidades y, una vez que haya terminado con su acción, agrupa las llamadas apropiadas a la base de datos y realiza las Solicitud a la base de datos. Este patrón es uno de los conceptos centrales utilizados por NHibernate , que utiliza un objeto que implementa IDisposible para señalizar el final del " trabajo " ;. Esto le permite envolver sus acciones en un uso y hacer que la unidad de trabajo se encargue de las acciones por usted.

Editar: Información adicional

Este es un enlace a la estructura de clases básica de la Unidad de Trabajo ... No es realmente la cosa más emocionante del mundo. Fowler proporciona más detalles en su libro, algunos de los cuales puede ver aquí . También puede ver el objeto Session de NHibernate como una posible implementación (pude rastrear ISession interfaz ... no estoy seguro de dónde se encuentra la implementación)

Espero que esto ayude.

Answer 2

Un enfoque que he usado en el pasado es hacer que el tipo de contenedor sea lo suficientemente inteligente como para recuperar los objetos requeridos. por ejemplo:

public class Relation<T>
{
  private T _value;

  private void FetchData()
  {
    if( LoadData != null ) {
      LoadDataEventArgs args = new LoadDataEventArgs(typeof(T), /* magic to get correct object */);
      LoadData(this, args);
      _value = (T)args.Value;
    }
  }

  public event EventHandler<LoadDataEventArgs> LoadData;

  public T Value {
    get {
      if( _value == default(T) )
        FetchData();
      return _value; 
    }
    set { /* Do magic here. */ }
  }
}

Luego lo declara en su entidad como:

[RelationCriteria("ID", EqualsMyProperty="AddressID")]
public Relation<Address> Address {
  get; set;
}

Y depende del cargador del tipo que declara la propiedad Dirección para agregar un controlador al evento LoadData.

Una clase similar implementa IList para darle una relación de uno a varios.

Answer 3

¿Qué idioma estás usando? Lo que describiste es exactamente lo que Entity Framework hace en .Net. Pero no compartiste el idioma que usabas y asumo que no quieres volver a escribir ninguno de tus datos.