Discussion :

[takinelinfo]

Bonjour à tous.
J'ai un petit problème de conception au niveau de la programmation orientée objet et du rôle que doit jouer chaque classes.
Je vais prendre un exemple pour illustrer mes dires.

Cas simple : une seule classeJ'ai l'habitude de créer mes entités dans un projet à part afin de pouvoir les référencer dans toutes les couches.

Code c# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
namespace Test.Application.EL
{
    public class UserEntity
    {
        public long Id { get; set; }
        public string Lastname { get; set; }
        public string Firstname { get; set; }
 
        public UserEntity(){
 
        }
    }
}

Pour tout ce qui est CRUD je créé un manager associé.

Code c# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
 
namespace Test.Application.DAL
{
    public class UserManager
    {
        public object Add(UserEntity user)
        {
            // 1) Check, si il y a des erreurs, renvoi d'une liste d'enum par exemple.
            // 2) Ajout de l'utilisateur à la base de 
            return user;
        }
 
        public UserEntity Get(long id)
        {
            UserEntity user;
            // Traitement
            return user;
        }
 
        public List<UserEntity> GetAll()
        {
            List<UserEntity> users;
            // Traitement
            return users;
        }
 
        public bool Delete(UserEntity user)
        {
            // Traitement
            return true;
        }
    }
}

Cas plus complexe : deux classes imbriquéesUn utilisateur peut posséder ou nom de compte. Un compte ne peut exister sans utilisateur. 0..1 <-->1

Code c# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
namespace Test.Application.EL
{
    public class UserEntity
    {
        public long Id { get; set; }
        public string Lastname { get; set; }
        public string Firstname { get; set; }
        public AccountEntity Account { get; set; }
 
        public UserEntity(){
 
        }
    }
}

Code c# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
namespace Test.Application.EL
{
    public class AccountEntity
    {
        public long Number { get; set; }
        public double Amount { get; set; }
 
        public AccountEntity()
        {
        }
    }
}

1) J'ai mis Account dans UserEntity mais aurait t'on pu mettre plutôt UserEntity dans Account
2) Faut il un manager UserManager et un AccountManager?
- Je en sais pas si c'est à UserManager d'insérer dans la table user et account.
- Si c'est UserManager qui insère dans user et qui appelle UserAccount pour insérer dans account
- Si c'est UserManager qui insère dans user et UserAccount qui insère dans account.
3) On verra le cas des 0..* <--> 0.* après

[Alikendarfen]

Bonjour,

Je prendrais le problème comme ça :

- Si un account ne peut appartenir qu'à un user (composition) :
Tout gérer dans userManager ou bien utiliser accountManager depuis userManager (accountManager serait un sous manager de userManager)

- Si ça n'est pas le cas (référence) :
Les deux entités ont une vie indépendante, donc il faut créer un accountManager. Et userManager peut cependant utiliser accountManager (pour obtenir l'id d'un account, par exemple)

Globalement, j'ai la même approche que toi :
- Objets métier
- Objets "manager" pour gérer la persistance des objets métiers
- Objets "module" (niveau fonctions applicatives) qui utilisent un ou plusieurs objets "manager"
- Objets "service" qui utilisent un ou plusieurs objets "module"

Seuls les objets métier sont connus de toutes les couches et les objets "manager" ne sont utilisés que par les modules. Mais rien n'empêche qu'un objet "manager" soit utilisé par plusieurs modules.

Pour concrétiser sur ton exemple, si l'object account fait partie de user, l'objet métier est l'user avec son account. Donc il n'y a pas d'objet métier account indépendant qui soit visible par les modules (l'objet account n'est vu que comme membre de l'objet user).

Éventuellement dans ce cas, tu pourrais avoir une classe AccountManager incorporée en tant que classe privée dans la classe UserManager. Mais à la limite, ça n'est plus qu'une question de taille et de lisibilité du code.

Qu'en penses tu ?