Interfaces et conversions d'objets

Bonjour à tous,

On est en train de se casser la tete avec deux collègues pour mettre en place un truc sympa et pratique sur l'appli que nous développons mais on bloque sur quelque chose.

Imaginons un projet "Library"
Il contient une interface qui sera donc mon contrat exposé au reste du monde.
Il contient également un objet implémentant cette interfaces. Par contre, cet objet n'est pas exposé au reste du monde.
Il contient enfin une classe exposant une fonction qui permet de retourner un objet typé IQuelquechose (donc mon interface). Le return renvoie une instance de ma classe mais le type du retour de fonction est bien mon interface.

Maintenant, je suis dans un projet Lambda qui référence ce projet Library.
Dans ce projet lambda, je créé une classe model qui implémente l'interface.
Je fais appel à la fonction de la classe me retournant mon IQuelquechose et j'essaye d'assigner ce résultat dans une variable typé mon model (qui implémente IQuelquechose) mais cela ne fonctionne pas.

Auriez vous une idée qui permettrai de caster, de convertir le résultat de ma fonction qui est un IQuelquechose (mais qui est encapsulé dans ma classe de mon projet Library) vers mon type model qui implémente lui aussi mon interface ?

On retourne le problème dans tous les sens et cette problématique est vraiment importante pour nous.

Citation:

---

Envoyé par zax-tfh

Auriez vous une idée qui permettrai de caster, de convertir le résultat de ma fonction qui est un IQuelquechose (mais qui est encapsulé dans ma classe de mon projet Library) vers mon type model qui implémente lui aussi mon interface ?

---

Ce n'est pas possible.

Si A et B sont des classes implémentant un interface I et que que A et B n'ont aucuns liens de parenté (je veux dire A dérive de B ou inversement) alors il est impossible à partir de B d'avoir un objet A même si les deux classes se trouvent dans la même librairie (donc out le fait qu'elles ne partagent pas la même librairie ou que l'une des classes n'est pas visible du monde extérieur).

La seule solution est de passer par un convertisseur (une classe intermédiaire permettant à partir d'une instance de A créer une instance de B et inversement) ce qui n'est pas du tout propre et oblige à ce que toutes les classes soient visibles par toutes les librairies si elles ne sont pas dans une seule et unique librairie :D

C'est bien ce que je pensais, merci.
Après je peux peut etre voir pour me faire un petit convertisseur qui, par reflection, va récupérer chaque property de mon interface et pour chacune d'entre elle transferer la valeur de A vers B. C'est pas ultra sex non plus mais ça a le mérite d'etre automatique et niveau perfs, s'il y a maxi 30 property c'est le bout du monde... donc le probleme ne se posera pas. Qu'en penses tu ?

C'est aussi une solution et elle t'évite grâce à la réflexion d'exposer la classe A (confère mon précédent post). Sinon je suis fan d'aucune de ces deux solutions :)

si tu as une interface ca devrait te suffire, si tu veux faire une 2ème classe qui implémente ton interface il faudrait nous donner la raison

après si tu veux que ton factory (c'est comme ca qu'on appelle un truc qui retourne une nouvelle instance) retourne une instance de ta 2ème classe plutot que la classe qui est dans la dll c'est possible aussi, même sans référence, il faut faire un mécanisme de "registration de classe"

En fait, le but de la manoeuvre serait de mettre à disposition une brique logique avec ses factory et ses interfaces.
A charge aux appelant de créer leurs propres classes implémentant ces interfaces.

Quel est le but de cette manoeuvre ?

Dans une équipe de devs, on est amenés, entre "secteurs logiciels" (donc entre différents produits), à faire appel à des briques logicielles communes. Néanmoins, l'utilisation directe de classes qui seraient exposées par la brique commune pose problème selon les frameworks employés.
En effet, dans le cas d'un site ASP MVC, on va avoir besoin de dataannotations pour valider les données par exemple.
Dans le cas de Silverlight, on va devoir ajouter la notion de PropertyChanged dans le setter de la property. D'où la nécessité de faire créer leurs propres classes à ceux qui utilisent cette brique logicielle.

Donc une brique hermetique avec juste des interfaces et des factory
Un ou plusieurs "appelants" qui vont créer leurs propres classes implémentant les interfaces et les décorant ensuite avec des mécanismes propres au framework utilisé (j'espere que mon explication est assez claire :) )

dans ta dll avec les interfaces tu veux faire une fonction à laquelle on passe un type de classe (et éventuellement un type pour l'interface bien que ca puisse se deviner)
le factory ira alors lire ce qui a été iniatialisé pour savoir quel type doit etre retourné
il suffit alors de faire un truc du genre return activator.Createinstance(letype)

Citation:

---

Envoyé par Pol63

dans ta dll avec les interfaces tu veux faire une fonction à laquelle on passe un type de classe (et éventuellement un type pour l'interface bien que ca puisse se deviner)
le factory ira alors lire ce qui a été iniatialisé pour savoir quel type doit etre retourné
il suffit alors de faire un truc du genre return activator.Createinstance(letype)

---

Peut-être que j'ai lu son problème à l'envers. Le problème de zax-tfh se résume tout simplement à ça et nom à la façon de créer des instances de classes :

Citation:

---

Si A et B sont deux classes qui implémentent toutes les deux un interface I alors est-ce qu'une instance de A peut être considérée comme une instance de B ?

---

Ma réponse à cette question est dans mon précédent commentaire. Peut-être les histoires de Factory que tu soulèves viennent à améliorer les solutions proposées précédemment.

Il me semble qu'il y a là un problème de conception.

Lorsque l'on manipule des interfaces, c'est qu'on ne veut pas dépendre d'une implémentation en particulier. Pourtant, c'est le cas de la fonction qui retourne une "instance de type IQuelqueChose"

Pourquoi l'objet implémentant l'interface dans le projet Library n'est pas visible de l'extérieur ?

A mon avis :
- C'est dans le projet Lambda que devrait se trouver la fonction qui retourne "instance de type IQuelqueChose" mais en utilisant l'implémentation de IQuelqueChose qui se trouve dans le projet Lambda.
- L'implémentation du projet Library (celle qui n'est pas visible de l'extérieur) n'a pas de raison d'exister (mais il y a peut être d'autres informations qui je n'ai pas).

My two cents, comme on dit outre-atlantique... :)

Citation:

---

Envoyé par h2s84

Peut-être que j'ai lu son problème à l'envers. Le problème de zax-tfh se résume tout simplement à ça et nom à la façon de créer des instances de classes

---

son problème n'est pas de caster A en B alors que c'est impossible, il cherchait à faire ca un peu au hasard pour répondre à sa problématique
à savoir, il a une dll avec une interface et peut etre une classe (je pense d'ailleurs que ce n'est pas utile, à moins d'avoir des cas ou la classe de base peut suffire)
sauf que dans certains projet, ce n'est pas cette classe qu'il veut mais une classe spécifique à la plateforme
or la dll ne sait actuellement pas quelle classe doit etre instancier via le factory



d'ailleurs il me vient d'autres solutions que de l'initialisation au démarrage pour définir quelle classe doit être utilisée

si c'est simple, une interface = une classe, tu peux dans ta dll faire une inspection de l'exe et des dll chargée à la recherche d'une classe implémantant l'interface en question, puis faire du activator.CreateInstance sur le type

ou encore que le factory prenne 2 paramètres, l'interface et la classe, du coup le factory semble inutile, mais au moins les instances sur l'interface peuvent transiter dans le programme, seuls les créateurs d'instances doivent connaitre la classe à créer

Voilà je suis d'accords avec les 2 commentaires de dessus :ccool: Il a un problème de conception c'est sûr :mouarf:

Oulah :)
Problème de conception : certainement, c'est d'ailleurs pour cela que je souhaite revoir ma structure et trouver la solution la plus propre.

Je vais exliquer ma problématique avec l'exemple :

J'ai un projet BusinessLayer (qui ne doit pas avoir de référence sur mes autres projets de ma solution) qui contient :
- CustomerFactory (il est chargé d'aller chercher en base mes infos et me rapatrier ça).
- Un élément (Interface, classe abstraite, peut importe) qui va servir d'enveloppe à mes données.

-> J'ai un projet ASP.MVC 4 qui contient un modele MVCCustomer qui doit exposer les mêmes propriétés que ce que me retourne mon factory MAIS sur lequel je dois pouvoir modifier le code de mes property (ajouter des dataannotations par exemple).

-> J'ai un projet Silverlight avec un Modele SLCustomer qui contient lui aussi les mêmes property MAIS sur lequel je dois pouvoir modifier le code des propriétés pour ajouter un RaisePropertyChanged dans le setter de mes property.

La question : Comment faire pour rendre la brique BusinessLayer compatible à mes deux projets (ASP.MVC et Silverlight) sans pour autant bouger chacun des éléments cités de leurs projets respectifs (le factory et sa logique métier reste dans la BL, les modeles restent dans les projets ASP et SL) ?

Aaaah, les attributs .net : ou comment ajouter du couplage sur des DTO !
Il me semblait bien qu'il nous manquait des infos :P

Peut-être que AutoMapper est la réponse à ta problématique : https://github.com/AutoMapper/AutoMapper

Par contre, je tique encore sur "l'élément qui va servir d'enveloppe aux données".
Si j'ai bien suivi, ce pourrait être un DTO (nu de tout attribut .net :P), que tu devrais mapper avec MVCCustomer et SLCustomer.
C'est bien ça ?
Dans tous les cas, ni une interface, ni une classe abstraite ne peuvent stocker des données.

Tu as bien saisi le principe skalp et je cherchais à voir s'il y avait des moyens un peu plus "propres" de gérer ce genre de cas (où alors une autre architecture).

Le but étant de rendre étanche la brique métier et surtout qu'elle soit vraiment dénuée de tout élément exterieur comme les annotations de validation ou alors les raisepropertychanged pour la partie SL ou encore les annotations de datacontract pour les WS. Tous ces cas étant gérés dans les projets propres à chacun.


En fait, cette recherche est la continuité de l'injection de dépendance.
En effet, les méthodes et fonctions de ma brique logique peuvent attendre des paramètres. Ces paramètres seront typés As IQuelquechose ce qui fait que la brique se servant de la brique logique va injecter son objet qui implémente l'interface et la brique logique pourra traiter la demande sans se soucier du type de l'objet envoyé en paramètre, à partir du moment où il implémente l'interface. La continuité dont je parle c'est qu'on fait de l'injection de dépendance en entrée mais comment fait-on pour reproduire le même principe en sortie ?

Citation:

---

Envoyé par zax-tfh

La continuité dont je parle c'est qu'on fait de l'injection de dépendance en entrée mais comment fait-on pour reproduire le même principe en sortie ?

---

En entrée et sortie de quoi ? Des fonctions ?
Peux-tu nous donner un exemple illustrant cette question ?

Entree sortie des fonctions factory en effet.
Un exemple :

Projet BLL :

Classe PersonFactory

Code:

---

1 2 3 4 5

Public Function GetPersonList(criteres as ICriteresSelectionPerson) as IEnumerableOf(IPerson) 'Ici je vais chercher en base ma liste d'éléments Person dim result as List(Of Person) = myDb.GetListPersons(criteres) return result End Function

---

Friend Class Person : implémente IPerson et expose les propriétés implémentées de IPerson

Public Interface IPerson : déclare les signatures de quelques propriétés

Projet MVC.Models

Public Class PersonModel : : Implémente IPerson et expose les propriétés de IPerson. Possède en plus des annotations de validation propres au projet MVC.
Public class criteresSelectionPerson : Implémente ICriteresSelectionPerson

Projet MVC :

classe PersonController

Code:

---

1 2 3 4 5 6 7 8 9 10

Function Index() as Action Result dim ListeModels as new List(Of PersonModel) dim pFactory as new PersonFactory for each Ip as IPerson in pFactory.GetPersonList(new criteresSelectionPerson) dim m as new PersonModel MonWrapperParReflection.Wrap(Ip, m) ListeModels.Add(m) Next Return View(ListeModels) End Function

---

Cette méthode de travail permet à n'importe quel projet, que ce soit du mvc, du webservice, du silverlight, d'utiliser cette couche BLL sans pour autant en modifier le contenu car on sépare bien la partie business et ses objets de la partie exploitation du business.

Maintenant, en reflechissant à ça, il est clair que cela demande beaucoup de travail derriere... Si je me casse autant la tête sur le sujet c'est que nous avons
- plusieurs projets business différents
- plusieurs projets les exploitant, tous dans un framework différent (mvc, silverlight...)
- Nous avons eu des déboires à partager les mêmes objets "Pseudo DTO" entre ces différents exploitants parce que d'une part nous avons des annotations de validation pour le MVC, parce que nous devons utiliser des types bien particuliers (observablecollection pour tout ce qui est liste pour que Silverlight les gère bien alors qu'un MVC n'en a rien à faire), parce que nous avons du ajouter le raisepropertychanged dans chaque setter (pour le silverlight), parce que nous avons les attributs de datacontract (pour la partie webservices), bref, c'est loin d'être l'utilisation optimale de ces projets. J'aimerai que chaque développeur puisse, qu'il soit dans un framework ou dans un autre, se concentrer sur son domaine à lui et qu'il n'ait pas à penser aux autres frameworks.

Bonjour,

Citation:

---

Envoyé par zax-tfh

...
J'ai un projet BusinessLayer (qui ne doit pas avoir de référence sur mes autres projets de ma solution) qui contient :
- CustomerFactory (il est chargé d'aller chercher en base mes infos et me rapatrier ça).
- Un élément (Interface, classe abstraite, peut importe) qui va servir d'enveloppe à mes données.

-> J'ai un projet ASP.MVC 4 qui contient un modele MVCCustomer qui doit exposer les mêmes propriétés que ce que me retourne mon factory MAIS sur lequel je dois pouvoir modifier le code de mes property (ajouter des dataannotations par exemple).

-> J'ai un projet Silverlight avec un Modele SLCustomer qui contient lui aussi les mêmes property MAIS sur lequel je dois pouvoir modifier le code des propriétés pour ajouter un RaisePropertyChanged dans le setter de mes property.

La question : Comment faire pour rendre la brique BusinessLayer compatible à mes deux projets (ASP.MVC et Silverlight) sans pour autant bouger chacun des éléments cités de leurs projets respectifs (le factory et sa logique métier reste dans la BL, les modeles restent dans les projets ASP et SL) ?

---

et

Citation:

---

Envoyé par zax-tfh

... J'aimerai que chaque développeur puisse, qu'il soit dans un framework ou dans un autre, se concentrer sur son domaine à lui et qu'il n'ait pas à penser aux autres frameworks.

---

Il faut peut-être regarder du coté des génériques pour le factory dans la brique BusinessLayer.


A+, Hervé.

Bonjour,

Merci pour la réponse mais j'ai du mal à voir comment les générique pourraient s'appliquer à ma problématique.
Serait-il possible d'expliquer un peu à quel niveau ils entreraient en oeuvre ?

Merci d'avance

Oui, effectivement les génériques peuvent répondre au problème !
Tu pourrais écrire quelque chose comme :

Code:

---

1 2 3 4 5

Public Function GetPersonList(Of T As {IPerson, New})(criteres As ICriteresSelectionPerson) As IEnumerable(Of T) 'Ici je vais chercher en base ma liste d'éléments Person Dim result As IEnumerable(Of T) = myDb.GetListPersons(Of T)(criteres) Return result End Function

---

Ainsi, tu injectes l'implémentation de IPerson qui va bien au moment d'appeler la méthode.
Par exemple, dans le projet MVC :

Code:

---

pFactory.GetPersonList(Of PersonModel)(new criteresSelectionPerson)

---

Plus besoin de mapper ! :)

Bonjour skalp,

Cette solution est de loin la plus élégante et la plus excellente !!!! c'est pile ce dont j'avais besoin et cela s'applique vraiment nickel chrome à la problématique que j'avais.
Juste une petite question au passage : que veut dire le ",new" dans la déclaration générique ? J'ai bien vu que si je le retire je ne peux plus faire de new T with {. [...] } mais je ne comprend pas vraiment ce que cela implique derriere.

Dans tous les cas, je te remercie beaucoup pour le coup de main, ca débloque un vrai gros probleme !

Cela veut dire que tu peux passer un "type de classe" en paramètre et récupérer une instance de ce "type".


Du genre
FABRIQUE

Code:

---

1 2 3

Public Shared Function FabriqueClasse(Of T As {New})() As T Return New T End Function

---

DAL

Code:

---

1 2 3 4 5 6 7 8 9 10 11

Public Function GetSingleDTO(Of T As {New})(ByVal Requete As String) As DTOBase Dim Reader As DbDataReader Dim parser As Object ' obligatoirement en objet, sinon si de type T => méthodes populate non connues Try If ExecuterReader(Requete, Reader) = 0 Then If Reader.HasRows Then Reader.Read() parser = DTOParserFactory.FabriqueClasse(Of T)() parser.PopulateOrdinals(Reader) Return parser.PopulateDTO(Reader) '...

---

Appel

Code:

---

1 2 3 4 5

Public Function GetPersonId(ByVal PersonId As String) As PersonDTO Const K_REQUETTE As String = "select * from personnes where PersonId = ?" Try DALApp.AjouteParam("PersonId", DbType.String, PersonId) Return DALApp.GetSingleDTO(Of DTOParser_Person)(K_REQUETTE)

---

Merci beaucoup pour ces explications !

Je suis étonné de ne pas voir ce genre de principe dans les tutos expliquant les archis N-Tiers car je suis vraiment dans une problématique entreprise et l'archi N-Tiers (Cf tuto ici même) s'arrete juste avant de traiter ce niveau. Je pense que beaucoup de monde pourrait gagner son temps à utiliser ce principe là.
Qu'en pensez vous (d'après vos propres experiences professionnelles de projets BLL inter projets front end)

Les génériques sont une vraie innovation dans la programmation orientée objet.
Ils ouvrent des perspectives vraiment intéressantes en terme de factorisation et de découplage du code.

L'exemple que donne rv26t est (vraisemblablement) inspiré de l'excellente série d'articles sur une couche d'accès aux données performante que je mentionne dans la traduction que j'ai faite de l'article Quelle est la différence entre un DTO et un POCO ? (voir les Liens utiles).
Je te recommande chaudement la lecture de ces articles. Je viens de voir que tu as déjà lu la traduction, puisque nous en avons un peu discuté. :)

Comme tu le dis, le principe de l'architecture "N-Tiers" s'arrête au niveau des couches. Elle ne présuppose pas de l'utilisation des génériques qui n'existent pas dans tous les langages objets.

Enfin, dans mon exemple, dans la déclaration générique, j'ai ajouté ce qu'on appelle des contraintes de type.
Cela restreint l'utilisation de la méthode aux seuls types qui implémentent l'interface IPerson et qui possèdent un constructeur vide public (New) de façon à ce que tu puisses créer une nouvelle instance de T.
En effet, sans connaitre l'implémentation de ta méthode, je me suis dit que tu aurais certainement besoin d'instancier les objets puisqu'il s'agit de la couche de persistance ! ;)
Et comme tu l'as vu toi-même, grâce à cette contrainte de type, tu peux écrire quelque chose comme :

Code:

---

Dim person As T = New T()

---

Sans ça tu ne peux pas.

Citation:

---

Envoyé par Skalp

...
L'exemple que donne rv26t est (vraisemblablement) inspiré de l'excellente série d'articles sur une couche d'accès aux données performante que je mentionne dans la traduction que j'ai faite de l'article ...

---

Je suis effectivement parti sur ces articles en langue anglaise.
Et j'ai essayé de creuser dans ce sujet pour rendre plus général (voir à partir du post 14) et la solution a été d'utiliser les génériques. (post 27)