Pattern Repository avec 2 services et 2 couches dataccess - C # DDD?

Question

Quelqu'un peut-il aider, j'ai 2 applications et ils sont presque identiques. ils ont une couche de présentation complètement différente (Web) et la logique métier et la base de données sont presque identiques. Fondamentalement, une application a certaines choses que l'autre ne fonctionne pas.

donc je me demandais si je peux faire ce qui suit sans enfreindre les règles etc

Chaque application a sa propre couche de présentation.
Chaque application a sa propre couche de service.
Chaque application a sa propre couche d'accès aux données.
Chaque application partage une autre couche de service.

D'où la couche de services partagés les deux applications peuvent accéder que la logique métier est identique, mais ils ont tous deux une autre couche de service qui a 5 ou 6 méthodes là-dedans qui sont spécifiques à cette application réelle

La couche d'accès aux données - Je ne vois pas de toute façon de partager cela comme il existe 2 DBs avec cadre d'entité d'où son obtenu l'EDM là-bas donc sa non dynamique -. Et les tableaux diffèrent légèrement

Je pourrais utiliser du CIO sur la couche d'accès aux données partagées je suppose

Quelqu'un veut aider ou commenter ce temps est une bonne pratique .. Ce que je ne voulais pas faire est d'avoir seulement une couche de service distincte lorsqu'une grande partie est partagée ..

Est-ce une bonne idée? Peut-être que je l'ai eu tort, est-il une meilleure façon?

Answer 1

Arjen de Blok dit, vos entités commerciales devraient utiliser un référentiel, un référentiel est un objet avec des méthodes pour interroger, mettre à jour ou insérer des entités de domaine.

L'interface qui décrit votre référentiel appartient à votre couche de domaine, mais la mise en œuvre appartient à la couche d'infrastructure (DAL).

Vous pouvez partager le domaine et les bibliothèques d'infrastructure entre deux de vos projets. Si ces deux projets devraient récupère leurs données via un service Web partagé ou une base de données partagée, il vous suffit de choisir (c.-à-injectez) la mise en œuvre correcte de votre référentiel (vos objets de domaine ne connaissent que l'interface de votre dépôt, pas du béton Type)

Answer 2

Si la logique métier est alors essentiellement identique vous devriez vous concentrer à ce premier. Si vous voulez faire DDD vous devez identifier vos entités et services (entreprises) d'abord et les placer dans une seule bibliothèque.

Ces entités et services aux entreprises devraient parler à votre couche d'infrastructure (votre DAL). Si la couche d'infrastructure est très différente dans ces deux applications puis essayez de travailler avec des interfaces. Donc, envelopper la couche intfrastructure avec des interfaces et parler uniquement de la couche de domaine à votre couche d'infrastructure via ces interfaces.

Pour lier votre logique métier à la mise en œuvre de votre infrastructure, vous pouvez utiliser IoC / DI.

Answer 3

Vous pouvez unifier le DAL avec une interface Repository. Vous pouvez ensuite implémenter l'interface entre les projets. Vous finirez probablement avec une classe de base du référentiel EF ainsi. Vous pouvez appliquer une technique similaire aux services, tirer parti d'une interface commune et ensuite se spécialiser les implémentations de service.