Limites des hiérarchies éparpillées
Bonjour à tous,
J'ai une solution décomposée en projet selon comme ceci :
libUtils (librairie statique)
libDatas (librairie statique)
libBusiness (librarie dynamique)
projet1 (exécutable)
- libUtils regroupe les petits utilitaires (mémoire, log etc...)
- libDatas regroupe la gestion des données.. sans les données. Tout est basé sur des templates. Ainsi, on gère la donnée A, B.... N tous de la même manière.
- libBusiness définit les objets métiers. Par exemple on aura la définition d'un client, et une fois définit on le lie à libDatas pour gérer tout ce qu'il y a autour d'une donnée (Input/Output, recherches, stockage, création, filtres etc...).
- projet1 : Utilise libBusiness pour faire coucher les données ensemble et répondre au besoin de l'utilisateur.
dans libDatas, nous trouverons des classes de ce style :
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
template<class T>
class CIdentData; // Une donnée identifiable
template<class T>
class CDataIo; // En fait une interface qui sera étendue en 2 classes pour le moment, une pour gérer une source de fichier texte, une autre pour une BDD
template<class T>
class CGesIdentData; // Stockage, fonctions de recherches etc... sur les données
template<class T>
class CDataFilter; // Un filtre sur une donnée T
template<class T, class U>
class CDataConnexion; // Une connexion entre deux données (pour reproduire les relations entre les tables, dans les objets). |
Bref, cette librairie ne gère que des T qui seront des clients, des véhicules, des commandes, définis par libBusiness.
Pour mettre à disposition cette banque de données (accès au CGesIsentData<T> et tout le reste) je ne voulais pas faire un singleton par gestionnaire de données. J'ai préféré utiliser une hiérarchie éparpillée :
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
typedef TYPE_LIST3(CClient, CVehicle, CCommand) TBusinessTypes;
template <class T>
struct SGesHolder
{
CGesIdentData<T> Ges;
};
class CGesManager : public CSingleton<CGesManager>, CScatteredHierarchy<TBusinessTypes, SGesHolder>
{
template<class T> unsigned int GetCount() const
{
return SGesHolder<T>::Ges.GetCount();
}
}; |
Ainsi, on ne tombe pas dans la "singletonite", et il y a un unique point d'entrée vers les données (ex: CGesManager::Instance().GetCount<CClient>())
Mais je ne suis pas sûr que ça soit "comme ça qu'il faut faire". En effet :
- Je dois gérer 53 classes métiers, ce qui rend la compilation assez longue le temps de générer toutes les classes templates)
- La librairie de gestion des données utilise une liste de type qui n'existe dans cette librairie (elle est définie par la librairie métier).
- Dans ma librairie métier, j'ai un fichier qui inclu toutes les entêtes de mes classes métier pour ensuite construire la liste de type à passer à la librairie de gestion de données. Chaque classe héritant d'une "donnée identifiable", est dépendante cette dernière librairie, donc doit inclure ce fichier qui détient la liste avant d'inclure le "CIdentData.h". Pour faire simple, chaque entête de mes classes métiers incluent (indirectement) toutes les entêtes de toutes les classes métiers. La conséquent est qu'à la moindre modification d'une entête, il faut tout recompiler.
Donc voilà, j'aimerai votre avis avant de continuer.
Merci beaucoup,
Aurélien
