Discussion :

[anthyme]

Bonjour,

Dans ma chasse aux ligne de code inutile, je constate qu'un de mes service WCF a énormément de redondance ...

par exemple pour des objet de type Toto, Tata et Titi j'ai ces méthodes dans mon service :

Code :

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

1
2
3
4
void CreateToto(Toto)
void EditToto(Toto)
void DeleteToto(Toto)
IEnumerable<Toto> ListTotos()

Code :

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

1
2
3
4
void CreateTata(Tata)
void EditTata(Tata)
void DeleteTata(Tata)
IEnumerable<Tata> ListTatas()

Code :

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

1
2
3
4
void CreateTiti(Titi)
void EditTiti(Titi)
void DeleteTiti(Titi)
IEnumerable<Titi> ListTitis()

chacune faisant appel a des BBL type : TotoBBL.Create(toto) etc

Bref déjà il y a redondance de méthode entre les type mais il y a aussi une "certaine" redondance entre Create Edit Delete qui au final ont les mêmes IO.

Bref c'est a moitier une recherche a moitier un débat que je lance (pour ceux que ça tente ) :

Comment factoriser intelligemment et efficacement tout ce code ?

Évidement il faut quelque chose efficace coté serveur mais également agréable coté client.

Le but n'est pas de recréer un Astoria évidement

[Hexba]

Hmmm tu pourrais essayer quelque chose du style,

Code :

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

1
2
3
4
5
6
7
8
9
10
 
public enum EnumActionTypes
{
      EAT_CREATE,
      EAT_EDIT,
      EAT_DELETE,
      (...)
}
 
public void manageToto(Toto ..., EnumActionTypes ...)

ça peut te permettre de conserver les lignes de codes communes et après il te reste à faire un switch sur le type d'action.

[B.AF]

Je crois que ça s'appelle une interface.

Code :

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

1
2
3
4
5
6
public interface ICommonBBL
void Create<T>(object o)
void Edit<T>(object o)
....
 
end interface

Code :

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

1
2
3
4
5
6
7
public class Toto : ICommonBBL
 
void Create<T>(object o)
{}
void Edit<T>(object o)
{}
End class

[anthyme]

@Hexba
J y ai pensé mais bon je sais pas je suis pas fan (c'est peut etre quand même ce qu'il y a de mieux )

@B.AF
Ça implique de faire plusieurs class donc plusieurs services et donc de la redondance de classes coté client dans les proxy générés.
De plus il faut quand même implémenter des méthode donc on ne gagne pas de lignes de codes.
Avec une classe abstraite à la rigueur mais cela ne regle pas le problemes des doublons de classes générés

l'idéal serai de pouvoir affiner la configuration des proxy

[B.AF]

Pourquoi ?

Si tu as une abstract pour ta factory / services;

Tu peux très bien construire ta factory avec un o;
En reflection obtenir le type et donc implémenter génériquement tes services.

Code :

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

1
2
3
4
Limite in fine :
Edit(object o)
Create(object(o))
Delete(object(o))

o.GetType() te permet de réfléchir le type donc de builder une instance du BBL associé;

Même mieux, tu peux utiliser Spring ou unity pour créer un contexte propre du BBL en fonction du type que tu utilise pour l'id de la factory que tu souhaites utiliser.
Une fois de plus à condition que tes BBL utilisent des interfaces qui permettent de généraliser leurs méthodes.

Mais bref.

[anthyme]

Effectivement c'est une solution vis a vis de la non redondance des méthode mais le problème que j ai soulevé est vis a vis de des proxy.

Si tu fait pour 2 class Toto et Titi
avec 2 service TotoService, TitiService (créer via héritage de la classe abstraite).
Maintenant j'ai d'autre méthode a mettre dans des service qui renvoie ou prend en entrée des graphes d'objet comportant des toto et titi.
Que je créé un nouveau service pour ces méthodes ou les ajoutes dans un de ces 2 service j'aurai ce problème :
Je crée un Service qui s'appelle GraphService, et bien coté client je vais avoir 3 proxy avec ces classes :

MonAssembly.TotoService.Toto
MonAssembly.TitiService .Titi
MonAssembly.GraphService.Toto
MonAssembly.GraphService.Titi

Ce sont des classe identique coté serveur mais incompatible coté client et cela pose des problèmes à l'utilisation (exemple récupérer un objet dans un service et vouloir le réutiliser dans un autre).


sinon pour ce que tu propose ensuite je vois ce problème :

Comment WCF va sérialiser les objets ? (en effet si on lui précise uniquement le type object il sera pas comment faire passer ses sous classes)

Sinon tu aurai un lien/explications/piste vis a vis de Spring ? le framework et vaste et je vaste et je vois pas de quoi tu parles