Discussion :

[silvinus]

Bonjour,

J'ai un petit soucis. Je cherche à créer un mini framework qui gerera mes accées base. Pour cela j'ai plusieurs projets qui corresponde à mes couches :
- Core.Data contenant les classes qui fera appel à une DAL static
- Core.Business héritant des objets de Code.Data
- Business contenant mes objets metiers et héritant de Core.Business

Le systeme fonctionne. Mon soucis est que pour le moment Core.Business référence Core.Data et Business référence Core.Business et... Core.Data.
Donc dès que je veux créer les IHM dans un projets metiers je suis obligé de référencé Core.Data et Core.Business pour pouvoir utilisé les objets metiers du Business. J'aimerai pouvoir supprimer ces références. Je pense qu'il faut passer par des interfaces mais je ne vois pas trop comment faire, si quelqu'un a une idée merci de me la donné .

[giova_fr]

aurai tu un ptit diagramme à nous fournir? je ne suis pas sur de comprendre le shema de ton appli...

Sinon

je dirais pour tes classes Core.data et Core.Business de faire un clic droit dessus, puis refactoring puis extraire l'interface.
ensuite tu place ces interfaces dans un nouveau projet librairie de classe

Ainsi, désormais tes classes business et data dependent de cette dll

Tu peux en plus de cela, placer dans ce nouveau projet un abstract Factory.

Ainsi tout ce qui aurait besoin d'utiliser tes classes Core.Data et Core.Business aurait une reference vers ton nouveau projet uniquement, tu ne sera plus dépendant de Core.Data et Core.Business

[silvinus]

Grosso modo on a :

IHM --> classe metiers -héritage-> Core.Business -héritage-> Core.Data

On retrouve le même shéma pour les listes.
Je pense que tu as compris mon problème car j'aime bien ta solution et je vais ésséyé de la mettre en place.

Merci beacoup

[Philippe Vialatte]

IHM --> classe metiers -héritage-> Core.Business -héritage-> Core.Data

Pourquoi fais-tu de l'héritage entre ces couches ?

Que tes classes métiers *utilisent* tes classes de Core.Business qui *utilisent* Core.Data, ok, mais pourquoi l'héritage ?

[giova_fr]

je pense plutot que -> signifie "depend de"

Que tes classes métiers *utilisent* tes classes de Core.Business qui *utilisent* Core.Data

Je ne suis pas d'accord avec toi, d'ailleur silvinus dit lui meme que ca lui pose probleme.

Tout ceci viole totalement le principe d'inversion des dépendances qui dit :

1) Les modules de haut niveau doivent être modifiés lorsque les modules de bas niveau sont modifiés.
2) Il n'est pas possible de réutiliser les modules de haut niveau indépendamment de ceux de bas niveau. En d'autres termes, il n'est pas possible de réutiliser la logique d'une application en dehors du contexte technique dans lequel elle a été développée.

[Philippe Vialatte]

Tout ceci viole totalement le principe d'inversion des dépendances

Rien a voir avec ta citation, le DIP, c'est justement l'inverse

Avoir un module de haut niveau qui hérites d'un module de bas niveau *est* une violation du DIP, vu qu'une modif sur ton module de bas niveau impacte le module de haut niveau

je pense plutot que -> signifie "depend de"

Non, c'est marque noir sur blanc dans chacun de ces posts, c'est un héritage

Ajouter une interface intermédiaire si on conserve l'héritage ne changera rien a son problème

[giova_fr]

dès que je veux créer les IHM dans un projets metiers je suis obligé de référencé Core.Data et Core.Business pour pouvoir utilisé les objets metiers du Business.

J'y lis une totale violation du DIP.

Ajouter une interface intermédiaire si on conserve l'héritage ne changera rien a son problème

La je suis totalement d'accord avec toi.

[Philippe Vialatte]

ah, tu parlais de sa situation initiale ?

Oui, de toute façon, sa situation initiale viole a peu près tous les principes de SOLID

SRP : parce que si toutes tes classes métier héritent de tes classes de DAL, elles se tapent les responsabilités de la DAL en plus
LSP : je ne vois pas comment remplacer les objets métiers par des objets DAL
ISP : euh...en fait, sans interface, il est pas viole, celui la

La première chose a faire, c'est de commencer par casser cet héritage, qui n'as pas de raison logique

Ah, oui, et pour ceux qui prennent la discussion en route (instant de pub...), les principes SOLID, c'est ca :
http://philippe.developpez.com/articles/SOLIDdotNet/

[giova_fr]

oui je recommande vivement à tous de prendre connaissance de ceci, si vous ne savez pas structurez votre programme, si des qu'il prend de l'ampleur il devient impossible à maintenir, visqueux, fragile, difficile à faire évoluer : c'est que vous avez besoin d'aprendre les principes de SOLID.

Je recommande egalement un excelent bouquin, ma bible de chevet :

Agile Principles, Patterns and Practices in c# de Rober C.Martin, edition Prentice Hall.

[silvinus]

je ne voulais pas entamer un débat . Je ne connais pas SOLID, je connais quelques principes que j'éssaie de mettre en place.
Ma DAL est static Le core.Data se charge d'y faire appel et le Core.Business hérite de Core.Data tout comme la couche contenant les classes métiers hérite de Core.Business. Mon IHM référence les 3 projets. Mon but était de ne référencé que la couche contenant mes objets metiers.
Merci pour toute ces info je vais m'instruire...

[silvinus]

Une dernière chose pour répondre à la question : Pourquoi l'héritage?
Parceque les classes contenus dans Core.Data (qui sont les classes de base de mes objets metier) on besoin de l'héritage pour la réfléction.
En fait dans Core.Data il a la classe DataTable cette dernière possède entre autre la méthode Load(DataTable poObject). Cette méthode appel la DAL et s'envoie. Grace à ca la DAL connais l'objet a charger et par réflection génère la requète Select. C'est pratique en fait. Sans l'héritage et juste avec une interface je suis obligé d'implémenter ma méthode Load() dans chacun de mes objets metiers?

[ctxnop]

Ah, oui, et pour ceux qui prennent la discussion en route (instant de pub...), les principes SOLID, c'est ca :
http://philippe.developpez.com/articles/SOLIDdotNet/

Très intéressant tout ca. Bon après je pense qu'il faut aussi peser le pour et le contre car tout ces principes sont contraignant. La contrainte apportée est parfois plus important que le gain de robustesse/flexibilité qu'ils apportent. Mais c'est sur que dans l'absolut c'est très intéressant de les connaitre et savoir les appliquer. Merci pour ce joli lien.

[Philippe Vialatte]

@silvinus:

ce que tu decris, c'est plus ou moins un pattern activerecord -> ton objet metier dispose d'une methode qui va recuperer les donnees en base.

Si ton objet métier a la responsabilité de récupérer ses données en base, et de se sauvegarder, tu ne vas pas échapper a des problemes de "melange" entre tes couches

Si tu veux découper un peu tes couches, tu peux essayer de faire un genre de repository, et de l'appeler a partir de classes dont le role sera de gerer la recuperation/sauvegarde des objets metiers depuis la bdd...

Genre, pour des produits, tu fais un productmanager (ou productfactory), qui va avoir une methode GetOneProduct, qui va appeler ton repository, qui lui va faire de la reflexion...

qq chose comme :

Code :

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

1
2
3
4
 
public Product GetOneProduct(int productId){
  return  _repository.GetOne<Product>(productId);
}

Et la methode GetOne<T> te fais un coup de reflexion pour determiner les differents accesseurs pour la generation de la requete....ca doit "a peu pres" correspondre a ce que tu fais deja, mais avec la factory en intermediaire

Perso, plutot que de m'embeter, je prendrais un ORM existant (de Subsonic a NHibernate en passant par EF, tu as le choix) qui te gerera tout ca touit seul comme un grand, avec des choses auxquelles tu n'as pas encore pense, et en plus avec certainement moins de bugs que ce que tu pourras faire (en tout cas, perso, c'est le choix que j'ai fait )

[silvinus]

Ok je te remercie pour toutes ces informations. Il est vrai que je n'ai pas pensé à passer par des choses éxistantes, c'est un tort. Je vais regarder les ORM qui se font. Mais aussi faire quelques Factory histoire de voire comment ca se passe.
En tout merci pour tout, et pour le temps que t'as passé à me répondre. J'apprécie.