Motif de chargement de l'entité commerciale

Question

Le projet sur lequel je travaille utilise une architecture à plusieurs niveaux. Nos couches sont les suivantes:

• d'accès aux données
• affaires Logique
• Entités d'affaires
• Présentation

Les appels Business Logic vers le bas dans la couche d'accès aux données, et les appels couche de présentation dans la couche Business Logic, et les entités Business sont référencées par chacune d'entre elles.

Nos entités commerciales correspondent essentiellement à notre modèle de données 1-1. Pour chaque table, nous avons une classe. Initialement, lorsque le cadre a été conçu, il n'y avait aucune considération pour la gestion des relations maître-détail ou parent-enfant. Ainsi, tous les éléments de la logique métier, de l'accès aux données et des entités métier ont uniquement référencé une seule table dans la base de données. Une fois que nous avons commencé à développer l'application, il est rapidement devenu évident que le fait de ne pas avoir ces relations dans notre modèle d'objet nous faisait gravement souffrir.

Toutes vos couches (y compris la base de données) sont toutes générées à partir d'une base de données de métadonnées interne que nous utilisons pour générer notre générateur de code local.

La question est quelle est la meilleure façon de charger ou de charger paresseux les relations dans nos entités. Par exemple, disons que nous avons une classe de personne qui a une relation maître-enfant avec une table d'adresses. Cela apparaît dans l'entité commerciale en tant que propriété de collection des adresses sur l'objet Personne. Si nous avons une relation un-à-un, cela apparaîtra comme une propriété d'entité unique. Quelle est la meilleure approche pour remplir et sauvegarder les objets relationnels? Nos entités commerciales n'ont aucune connaissance de la couche Business Logic, de sorte qu'elle ne peut pas être effectuée en interne lorsque la propriété est appelée.

Je suis sûr qu'il existe une sorte de modèle standard pour faire cela. Aucune suggestion? En outre, une des réserves est que la couche DataAcess utilise la réflexion pour construire nos entités. Les procédures stockées retournent un résultat selt basé sur une table, et en utilisant la réflexion, nous peuplons notre objet métier en faisant correspondre les noms des propriétés avec les noms des colonnes. Faire des jointures serait donc difficile.

Answer 1

Je recommande fortement de consulter le livre de Fowler Patterns of Enterprise Architecture. Il y a quelques approches différentes pour résoudre ce genre de problème qu'il décrit gentiment, y compris les relations d'entité.L'un des éléments les plus convaincants serait le motif Unit Of Work, qui est essentiellement un collecteur, qui observe les actions effectuées sur vos entités, et une fois que vous avez terminé votre action, il effectue les appels de base de données appropriés, et rend la demande à la base de données. Ce modèle est l'un des concepts centraux utilisés par NHibernate, qui utilise un objet qui implémente IDisposable pour signaler la fin du "travail". Cela vous permet d'emballer vos actions dans une utilisation et de faire en sorte que l'unité de travail gère les actions pour vous.

Edit: Informations supplémentaires

This est un lien vers la structure de classe de base de l'unité de travail ... pas vraiment la chose la plus excitante dans le monde. Fowler fournit plus de détails dans son livre, dont certains peuvent voir here. Vous pouvez également regarder l'objet Session de NHibernate comme une implémentation possible (j'ai pu suivre l'interface ISession ... je ne sais pas où l'implémentation se trouve)

Espérons que cela aide.

Answer 2

Quelle langue utilisez-vous? Ce que vous avez décrit est exactement ce que fait Entity Framework dans .Net. Mais vous n'avez pas partagé quelle langue vous utilisiez et je suppose que vous ne voulez pas réécrire un de vos datalayer.

Answer 3

Une approche que j'ai utilisée dans le passé est de rendre le type de conteneur assez intelligent pour récupérer les objets requis. par exemple:

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. */ } 
    } 
} 

Ensuite, vous déclarez sur votre entité comme:

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

Et il est au chargeur du type qui déclare la propriété d'adresses pour ajouter un gestionnaire à l'événement LoadData.

Une classe similaire implémente IList pour vous donner une relation un-à-plusieurs.