Transmission de données entre la couche de gestion et la couche d'accès aux données - code incorrect?

Question

J'utilise le code suivant dans la classe JCProperty pour récupérer des données à partir d'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 

Cela fonctionne bien, mais exige que l'objet DAL (JCPropertyDB) est au courant de l'objet métier (JCProperty) et je créer et peupler efficacement deux fois le même objet (une fois dans la couche d'accès logique pour retourner dans la zone BL, puis à nouveau dans l'objet zone BL pour se peupler).

Il me manque quelque chose ici, je sais qu'il doit y avoir un meilleur moyen!

Effectivement j'ai besoin d'assigner 'Me = x' ce qui n'est pas autorisé. Quelqu'un peut-il me mettre droit?

Answer 1

Personnellement, je suis paresseux. Je fais quelque chose comme:

class JCProperty : inherits JCPropertyDB 
    { 

    New() 
     { 
     MyBase.New() 

     GetProperty(PropertyID) 

     } 
    } 

Ensuite, vous êtes essentiellement fait, jusqu'à ce que vous avez des fonctionnalités supplémentaires dans la classe JCProperty qui doit se produire « sur » les fonctionnalités déjà existantes dans JCPropertyDB. Ensuite, vous surchargez les méthodes JCPropertyDB pour appeler la méthode de base en premier, puis ajoutez votre nouvelle fonctionnalité.

Ron

Answer 2

Vous ne savez pas si cela va répondre à votre question, mais le point important est que le modèle de domaine est indépendant de l'affichage et indépendant du stockage. Ceci est souvent désigné comme la séparation des préoccupations. L'idée est d'obtenir des couplages lâches et de créer un système simple où les objets n'ont pas plusieurs responsabilités complètement différentes.
Donc, ce que je ferais, est de permettre à la couche d'accès au contenu de créer des objets métier directement, mais assurez-vous que je ne contamine pas mes objets métier avec quoi que ce soit lié à la couche d'accès au client. De même, je ne veux pas les contaminer avec des choses spécifiques à l'interface utilisateur comme HTML. À mon avis, il est normal que la couche de gestion, la couche DAL et la couche UI aient toutes des dépendances avec le modèle de domaine, mais il n'est pas acceptable d'avoir des dépendances du modèle de domaine et de ces autres composants.
Pour desserrer les accouplements, l'utilisation de quelque chose de ressort ou de tout autre récipient d'injection de dépendances ainsi que des interfaces et du câblage peuvent vous aider. En recréant le même objet dans chaque couche, vous violez le principe DRY (Ne vous répétez pas) et vous introduisez le code de la plaque de la chaudière et augmentez le risque d'introduire une erreur quelque part.

Answer 3

Vous êtes sur les lignes droites manquantes cependant un point légèrement.

En règle générale, votre couche d'accès aux données (DAL) renvoie Data Transfer Objects (DTO) à partir de votre base de données. Il s'agit d'objets POCO (Plain Old CLR) qui ne contiennent aucune logique métier, simplement des propriétés correspondant plus ou moins aux tables de la base de données.

Vous auriez alors un code qui crée un Domain Model à partir de ces DTO, appelé Data Mapper. Les classes du modèle de domaine peuvent avoir des noms similaires (c'est-à-dire CustomerDTO -> Customer) mais en plus des données, elles contiendront des règles de validation et éventuellement d'autres logiques métier.

C'est ce modèle de domaine que vous utilisez ensuite dans votre couche de gestion, pas les DTO réels. Cela signifie que si vous modifiez les DTO renvoyés par le DAL (c'est-à-dire en implémentant un nouvel outil ORM), il vous suffit de modifier votre Data Mapper à condition que le modèle de données reste le même.

Je recommande d'examiner Martin Fowler's Patterns of Enterprise Application Architecture pour les modèles d'accès aux données.

Answer 4

Départ: http://www.icemanind.com/layergen.aspx

Answer 5

J'ai pris dans et BOs renvoyer BOs de la DAL via le modèle de pont et le modèle de fournisseur. Je ne peux pas voir le point de DTO sauf si j'avais peur de la sérialisation lourde (disons un service web ou JSON). Mon approche a consisté à extraire la couche Data-Layer et Business via une interface et à fournir une couche de données anonyme alimentée dans l'objet métier. Cela signifie que je peux brancher n'importe quelle couche de données, implémenter une interface qui a des méthodes universelles Load and Save et qui est ensuite accessible via ma couche de domaine. Il n'y a pas de code DAL dans le BL - simplement un appel à une couche de données fournie et abstraite. Mon appel à la couche de données est gérée par un modèle de fournisseur (pas de référence directe) et je fais simplement:

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

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

} 

dans la couche de données dont je dispose ...

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

Je ne toujours » Je ne sais pas si c'est bon mais ça marche plutôt bien pour moi. J'ai réussi à obtenir une charge paresseuse aussi bien pour les objets imbriqués en utilisant la réflexion.