Discussion :

[anthyme]

Bonjour !

Je suis tombé sur un article très intéressant présentant une architecture WPF/WCF/Linq2SQL

Très intéressant car moi je voulais me faire un mini jeu mmo en Silverlight/WCF/Linq2SQL

mais la je me pose quelques question vis a vis de son architecture...

Déjà il redéfini a chaque fois ses classe modèles avec des data contract et fais la copie dans la couche Bussiness entre ses class modèles et contract.

N'est pas un mauvais choix d'avoir du code en double ? (le pire anti-pattern pour moi) est ce qu'on aurai pas pu faire une interface de contrat et faire que les class modeles implemente cette interface ? mais comment faire car c du code "design" qu'on ne peut pas modifier sous peine de perdre la connection de l'EDI à la base de donnée...

Sa couche business est composé uniquement de CRUD et ses service ne font qu'exposer ce CRUD et le metier se trouve dans la partie cliente. Pour son application cela fonctionne mais pour moi cela poserai un gros problème de fonctionner comme cela car n'importe qui peu faire n'importe quoi si il modifie le client en WPF.
Donc pour moi il n y a que 2 solutions : être totalement sur que le client est bien celui que j ai distribué (mais est ce faisable ? même si je crée du code qui fait cela la personne fait un coup de reflector sur l'appli distribué et hop il peu voir comment cela se passe et l'adapter a un client "pirate") ou alors déplacer le metier de l'appli coté serveur, mais ou le placer ? dans la couche Business a la place de la DAO ? Devant la DAO ?

Sinon je pose une question à part de cette article.
En gros il y aura plusieurs "Pages" (fenetre?onglets?) dans une Page silverlight "mère" du coté du client, est ce que je doit mettre tout le xaml coté silverlight (lourd a téléchargé au début) ou bien est ce que je devrais plutôt envoyer le XAML des "pages" par les WCF ?

J'espère que ces problématiques en intéresseront plus d'un

Merci

[The_badger_man]

Déjà il redéfini a chaque fois ses classe modèles avec des data contract et fais la copie dans la couche Bussiness entre ses class modèles et contract.

N'est pas un mauvais choix d'avoir du code en double ? (le pire anti-pattern pour moi) est ce qu'on aurai pas pu faire une interface de contrat et faire que les class modeles implemente cette interface ? mais comment faire car c du code "design" qu'on ne peut pas modifier sous peine de perdre la connection de l'EDI à la base de donnée...

Dans le designer VS2008 tu peux spécifier que les classes générées doivent être utilisables avec WCF.

[cinemania]

meme sous VS2005 avec les extensions WCF et WPF et le sp1 d'installé.

maintenant un mmo sous forme de pages.. je suis septique, enfin bon.
il ne faut pas confondre non plus la partie BO, BL, DAO et WPF... deux choses à part...
WPF gére uniquement la partie design pour l'interface utilisateur... En aucun cas tu ne peux tout redéfinir dedans... En effet, tu ne peux pas crér un nouveau bouton si le code derrière n'a pas été concut dans cette optique...

maintenant pour la partie client/serveur, et le fait d'utiliser des webservice par WCF.
Générallement on a un interface qui fait office de Contrat de service, puis des classes de business object eventuellement que l'on déclare en DataContract, qui font office de contrat de données, cad les données échangeable par le webservice, autre que les données de bases.
Ensuite générallement le business logic ou buiness manager, est justement le service exposé, qui implante le Contrat de service fournit, coté SERVEUR.
Maintenant il n'est pas rare que ce business manager ne soit qu'un adaptateur vers un vrai gestionnaire qui lui est géré en singleton au niveau d ton appli, ou carrément en statique ou je ne sais quoi encore.
Générallement dupliquer du code n'est pas utile, mais ce n'est pas forcément de l'anti pattern design.

Duppliquer du code est parfois nécessaire, bien qu'avoir du code de BLL dans le BOL... pas top et vice versa

Ensuite parlons un peu architecture.
Générallement vu le type d'applicatif, on est dans le cas d'une architecture distribuée multiservices. En effet, un seul service "unique" est une perte de temps, et rend le code illisible coté adaptateur coté serveur, meme s'il ne fait qu'adaptateur.
Il est préférable là aussi de séparer les responsabilités et d'avoir plusieurs services.
De toute façon il est possible de mutualiser, les temps de connexion au service en établissant les connexions simultannéement via des thread de la pool ou des threads spécialisés.

Si tu laisse le XAML sur le serveur et le soin au client de charger le XAML, il doit donc charger deux choses... le corps et le descripteur... le pb, c'est que générallement, si des miss à jour de dsign sont efftcuée, rien ne dit qu'il va systèmatiquement chargé le xaml, il peut simplement gardé celui k'il a en cache.
Maintenant si tu créer ce qui faut coté service pour transferer les xaml, le probleme est toujours le meme finalleemnt. Simplement tu peux t'assurer que le client à le XAML que tu souhaite, mais il te reste un probleme....
comment dire à "l'applicatif" que le xaml arrive après, que tu le gere toi meme, et comment savoir où le stocker pour être sure que l'applicatif aille l'utiliser...

Dans le cadre d'un client lourd, typiquement client de jeu en ligne genre wow ou autre, il est relativement aisé de le faire... dans le cadre d'un systeme silverlight... là je l'ignore

[anthyme]

Dans le designer VS2008 tu peux spécifier que les classes générées doivent être utilisables avec WCF.

Hummm mais il faudrait que j'ajoute ma DLL DataAccessLayer aux référence de mon application silverlight.
Ce qui fait que potentiellement, quelqu'un peut décompiler mon application et connaitre toute ma couche d'access aux données.
Vous pensez vraiment que c'est une bonne solution ?

maintenant un mmo sous forme de pages.. je suis septique, enfin bon.
il ne faut pas confondre non plus la partie BO, BL, DAO et WPF... deux choses à part...

En fait quand je disais des "pages" je pensais à l'opposition WPF/silverlight Window/Page mais ce que je voulais dire c'est : "des composants graphique de mon application ressemblant plus ou moins a des fenetres"

WPF gére uniquement la partie design pour l'interface utilisateur... En aucun cas tu ne peux tout redéfinir dedans... En effet, tu ne peux pas crér un nouveau bouton si le code derrière n'a pas été concut dans cette optique...

humm je ne suis pas sur de comprendre, tu parles du fait que le xaml seul ne se suffit pas, c'est cela ? On ne peut pas télécharger le code behind qui va avec le XAML via une couche de service?

Duppliquer du code est parfois nécessaire, bien qu'avoir du code de BLL dans le BOL... pas top et vice versa

Tu peux me dire ce qu'est le BOL stp ?

un seul service "unique" est une perte de temps, et rend le code illisible coté adaptateur coté serveur, meme s'il ne fait qu'adaptateur.
Il est préférable là aussi de séparer les responsabilités et d'avoir plusieurs services.

Pas de probleme j'etais dans cette optique

De toute façon il est possible de mutualiser, les temps de connexion au service en établissant les connexions simultannéement via des thread de la pool ou des threads spécialisés.

idem

Si tu laisse le XAML sur le serveur et le soin au client de charger le XAML, il doit donc charger deux choses... le corps et le descripteur... le pb, c'est que générallement, si des miss à jour de dsign sont efftcuée, rien ne dit qu'il va systèmatiquement chargé le xaml, il peut simplement gardé celui k'il a en cache.

Tu pourrais m'expliciter la difference entre corps et descripteur s il te plait

Maintenant si tu créer ce qui faut coté service pour transferer les xaml, le probleme est toujours le meme finalleemnt. Simplement tu peux t'assurer que le client à le XAML que tu souhaite, mais il te reste un probleme....
comment dire à "l'applicatif" que le xaml arrive après, que tu le gere toi meme, et comment savoir où le stocker pour être sure que l'applicatif aille l'utiliser...

Franchement je n'en ai aucune idée ...

Dans le cadre d'un client lourd, typiquement client de jeu en ligne genre wow ou autre, il est relativement aisé de le faire... dans le cadre d'un systeme silverlight... là je l'ignore

... et parce que j'ai bien peur qu'il soit impossible de mettre en cache ce genre de chose que je n'aimerai pas que l'utilisateur recharge toute l'appli a chaque fois

merci pour vos réponses, je sens bien que je ne suis pas tout a fait au point sur ce genre d'archi et ca fait plaisir de se faire aider

[cinemania]

excuse moi pour l'usage des termes barbare BOL et BLL..

BOL : Business Object Layer (couche Business Objects)
BLL : Business Logic Layer (couche Business Logic)

l'usage de .NET suppose de toute facon qu'il est toujours possible d'obtenir le code source depuis la version compilée.
en revanche, la couche d'accès aux données ne se fait réellement que coté serveur, c'est pareil pour le business logic.

L'usage d'un webservice, suppose que c'est le webservice qui fera l'accès aux données, créera et je ne sais quoi d'autre les BO... finallement coté client, donc enduser, le code behind ne contiendra pas l'implantation de ta BLL, car silverlight ou pas, cela reste avant tout une technologie Web... client / server.
Le webservice est hébergé par le serveur web, donc.... personne a part l'administrateur de la machine n'a accès au code du webservice....
hors je le repéte si ton architecture est suffisamment disitribuée, la partie logique et l'accès aux données, est effectuée COTE SERVEUR !
je te rappel qu'avec WCF ou meme .NET Remoting, coté client tu n'a jamais que le contrat de service, et ce que tu récupere est un PROXY... pas la classe elle meme et encor emoins son implantation ! (toute facon ten ferais quoi ? elle pourrait pas tourner coté client lol)

Maintenant XAML c'est du XML... c'est donc un langage descriptif... descripteur de design finallement. Il n'ya pas vraiment de code dedans.
Le corps c'est le code lui meme
Le problème c'est que j'ignore si tu peux demander à silverlight de dissocier les deux et d'aller chercher le descripteur XAML là ou toi tu le veux, après que l'appli soit déja lancée, car il est là le pb, l'appli silverlight doit déja etre lancée...

[anthyme]

excuse moi pour l'usage des termes barbare BOL et BLL..

BOL : Business Object Layer (couche Business Objects)
BLL : Business Logic Layer (couche Business Logic)

Pas grave

Donc en gros dans l'article ci dessus le BOL c'est sa DLL Common

l'usage de .NET suppose de toute façon qu'il est toujours possible d'obtenir le code source depuis la version compilée.
en revanche, la couche d'accès aux données ne se fait réellement que coté serveur, c'est pareil pour le business logic.
[...]
Le webservice est hébergé par le serveur web, donc.... personne a part l'administrateur de la machine n'a accès au code du webservice....
hors je le repéte si ton architecture est suffisamment disitribuée, la partie logique et l'accès aux données, est effectuée COTE SERVEUR !
je te rappel qu'avec WCF ou même .NET Remoting, coté client tu n'a jamais que le contrat de service, et ce que tu récupere est un PROXY... pas la classe elle même et encore moins son implantation ! (toute facon ten ferais quoi ? elle pourrait pas tourner coté client lol)

Je suis d'accord pour le fait que cela ne puisse pas tourner coté client mais ce que je ne comprend pas c que l'appli cliente de WCF elle doit avoir les définitions de ces classes en liant a la DLL contenant ces classes (par exemple dans l'article il ajoute comme référence la DLL common a sa DLL UI) mais si je fais comme dit plus haut par The_badger_man la déclaration de contrats dans l'éditeur de linqtosql sur mes entities, je vais devoir donner en référence a ma DLL UI la DLL DAL et donc on pourra y voir le code de ma couche DAL vu que la DLL est coté client.
D'ailleurs je ne vois pas de proxy dans le code de cet article, il mesemblait que les proxy etait que pour SOAP et pas WCF, tu es sûr de ne pas confondre ?

Maintenant XAML c'est du XML... c'est donc un langage descriptif... descripteur de design finallement. Il n'ya pas vraiment de code dedans.
Le corps c'est le code lui meme
Le problème c'est que j'ignore si tu peux demander à silverlight de dissocier les deux et d'aller chercher le descripteur XAML là ou toi tu le veux, après que l'appli soit déja lancée, car il est là le pb, l'appli silverlight doit déja etre lancée...

Mwé c'est pas gagné tout ça j'espère qu'il va bien evoluer au cour de l'année et qu'un maximum de "good practice" vont ressortir

[The_badger_man]

Hummm mais il faudrait que j'ajoute ma DLL DataAccessLayer aux référence de mon application silverlight.
Ce qui fait que potentiellement, quelqu'un peut décompiler mon application et connaitre toute ma couche d'access aux données.
Vous pensez vraiment que c'est une bonne solution ?

A ce moment là tu fais comme dans l'exemple. Les classes "datacontract" ne sont pas celles utilisées dans la couche business.
Où alors j'ai pas compris la question.