Domain-Driven Design: DAL, DAO, DTO, POCO, Repo et contextes

[Finality]

Bonjour tout le monde,

Après avoir mis en place une architecture en Domain Driven (vous pourrez là retrouver sur ce lien), nous avons commencé à développer notre application.

Néanmoins nous rencontrons actuellement un problème et j’aimerai savoir si vous auriez certaines pistes à nous proposer. En avant pour la petite explication :

J’ai une méthode d’un controler qui récupère une liste d’id (par exemple d’id de classes).

Cette action instancie un objet de type User, puis fait appel à un repository pour récupérer l’ensemble des classes correspondant à la liste des ids :

Code :

1
2
3
4
5
 
public Classe GetClass(int id)
        {
            return  DataContext.CLASS.FirstOrDefault(d => d.IdClass== id);
        }

Elle insère par la suite ces objets dans l’objet User :

Code :

1
2
3
4
5
 
foreach (int id in model.SelectedId)
{
 user.Classes.Add(repo.GetClass(id));
}

Une fois cela fait, on fait appel à un autre repository pour insérer cet objet en BDD.

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
public bool AddUser(User user)
        {
            try
            {
                DataContext.AddObject("USER", user);
                DataContext.SaveChanges();
                return true;
            }
            catch
            {
                return false;
            }
        }

Et là, paf erreur : un message me dit qu’il est impossible d’ajouter un objet déjà rattaché à un context. J’en déduis donc que cela provient de mes classes qui doivent être ratachées à un context.

D’où ma question : auriez-vous des solutions à me proposer ? Nous essayons de développer l’application de la manière la plus propre possible, et nous souhaiterions éviter toute rustine ou combine

Merci pour votre aide,

Finality

[gyzmau]

Bonjour,

Je vais pas répondre directement a ta question .

Sur mes archis Je fais en sorte que mon context soit "linker" au cycle de vie du projet.

Ex: Dans la cas d'un projet web mon context aura un cycle de vie par request comme ca dés que je touche a mes entités dans une request ils seront sur le même context.
Si je suis plutôt sur un service d’exécution de tache mon context est lié au cycle de vie du thread exécutant pour la même raison que ci dessus.

Je sais pas si une bonne méthode elle marche plutôt pas mal. J'ai de mauvais souvenir avec EF lorsque qu'il faut balader des entités entre des contexts.(ces souvenirs datent un peu ils ont du peut etre améliorer, mais j'ai pas regarder)