Création d'objet Fowler Data Mapper

Question

J'ai utilisé les modèles Fowler pour les modèles de domaine avec un Data Mapper et j'ai rencontré des confusions sur la façon d'implémenter la partie création de CRUD. Je ne peux pas utiliser les technologies ORM existantes car les sources de données sous-jacentes sont des systèmes personnalisés. La zone qui me dérange est de savoir comment appeler le sous-officier ORM lorsque j'ai besoin de créer un nouvel objet. Ma couche de domaine n'a aucune visibilité sur mon ORM, à l'exception de mes trouveurs.

Je ne suis pas sûr si je suis sur la bonne voie, mais les suivantes sont les seules options que je peux voir:

1. gérer les fonctions créer de la même manière les trouveurs Fowler sont faits. Créez une interface dans la couche Modèle de domaine pour les méthodes de création sur les classes ORM. Demandez ensuite au modèle de domaine d'appeler un conteneur DI et d'instancier une instance de la classe ORM en fonction de l'interface. Pendant l'hydratation de l'objet A dans l'ORM, attacher un délégué pointant vers la méthode de création sur l'ORM pour l'objet B. L'objet domaine A étant hydraté, vous pouvez appeler le délégué sur l'objet A qui appelle la méthode create sur l'objet Le mappeur de B

2. ???

Je dois manquer quelque chose, car cela ne peut pas être si complexe. Toute aide serait grandement appréciée.

Merci

Answer 1

Que diriez-vous de voir comment ORM résoudre ce problème? Dans les langages qui prennent en charge la création dynamique d'objets, le «mappage» de la manière dont les données se rapportent aux objets de domaine est fourni en tant que configuration distincte. Les classes sont créées par réflexion ou par une bibliothèque de bytecode. Je suppose que cela dépend de la façon dont vous souhaitez créer le Data Mapper. D'après ce que je peux rassembler à partir du modèle original, les mappeurs de données peuvent exister par objet de domaine.

Vous essayez peut-être une solution générale. Sinon, il peut s'agir de configurer un mappeur général avec des informations sur la façon de construire les objets en utilisant la réflexion.

C'est aujourd'hui la couche ORM qui peut gérer les chaînes qui représentent le nom CanonicalClass + une liste de méthodes à attendre sur ces classes.

En passant d'un objet à persister l'objet peut être inspecté en utilisant cette information. Créer un objet peut être fait en utilisant la réflexion en utilisant les données de la base de données. Certaines solutions ORM peuvent ne pas créer l'arborescence des objets de manière approfondie, mais créer des proxys pour la récupération paresseuse.

Answer 2

Si votre problème est simplement de mapper du type A au type B, vous pouvez envisager AutoMapper.

Answer 3

Re: « comment appeler l'ORM sous-jacente quand je dois créer un nouvel objet »

Avez-vous regardé dans l'idée de ROOT et les motifs AGGREGATE de RÉFÉRENTIEL - ils pourraient être utiles.

En résumé: AGGREGATE ROOT est une 'entité' qui possède un identifiant global unique dans le système. La plupart du temps, ce sont les seuls objets que votre application devra saisir par ID. Ils sont trouvés à travers un REPOSITORY qui est généralement initialisé à connaître sur les couches de données au démarrage de l'application/bootstrap.

Les USINES pour RACINES AGRÉGULÉES sont également généralement initialisées à et connaissent à propos des couches de données au démarrage/amorçage de l'application.

Le REPOSITORY peut alors jouer un rôle de médiateur dans le processus de recherche des données pour l'objet, de quelque manière qu'il le souhaite. REPOSITORY délègue à la couche de données/mappeur pour obtenir les données brutes et tend à déléguer le travail de reconstitution de l'objet à une USINE (classe/méthode) pour faire le bâtiment. Le REPOSITORY renvoie alors l'objet NOUVELLE RACINE AGRÉGÉE ou (collection- de) au client qui a invoqué la méthode find du REPOSITORY - c'est-à-dire l'application. Le REPOSITORY est l'interface pour récupérer et sauvegarder les RACINES AGRÉGÉES et donne le comportement de celles-ci en mémoire.

Une application peut toutefois utiliser directement une FACTORY pour créer un tout nouvel objet AGGREGATE ROOT. L'usine d'une ROTATION AGRÉGÉE a une bonne connaissance des couches ORM/Mapper et, lors de la création d'une toute nouvelle entité, elle peut faire appel à une sorte d '«objet de séquence numérique» pour obtenir son identifiant unique.

RACINES GLOBALES sont généralement les seuls types d'objets de domaine que vous devez « Trouver par Id globalement connu » parce que tous les autres objets de domaine sont soit:

• objets de valeur jetables - comme une valeur monétaire ou
• Entités 'AGREGATION ROOT dépendante'. C'est à dire. les objets qui ont ids qui ne sont uniques dans le contexte d'une ROOT AGGREGATE ce qui implique que devrait vraiment être
  • ROOT AGGREGATE la seule chose qui doit trouver/utiliser - en interne
  • ils peuvent être trouvés par en utilisant le mappeur ORM de l'aggrégat ROOT
  • leurs ids peuvent être créés par le ROOT AGGREGATE qui définit son contexte/champ

Lectures complémentaires:

Voir Domain Driven Design, Eric Evans.

Racine globale: http://books.google.co.uk/books?id=7dlaMs0SECsC&lpg=PP1&dq=domain%20driven%20design&pg=PA147#v=onepage&q=&f=false

Repositroies: http://books.google.co.uk/books?id=7dlaMs0SECsC&lpg=PP1&dq=domain%20driven%20design&pg=PA147#v=onepage&q=&f=false

Answer 4

Si vous implémentez sur .NET, comme Richard a suggéré consulter AutoMapper. Si vous mettez en œuvre en Java, consultez ModelMapper.