[linq to SQL/WCF/Silverlight] Architecture

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 :)

Citation:

---

Envoyé par anthyme

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.

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 :)

Citation:

---

Envoyé par The_badger_man

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 ?

Citation:

---

Envoyé par cinemania

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"

Citation:

---

Envoyé par cinemania

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?

Citation:

---

Envoyé par cinemania

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 ? :oops:

Citation:

---

Envoyé par cinemania

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 ;)

Citation:

---

Envoyé par cinemania

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

Citation:

---

Envoyé par cinemania

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 :)

Citation:

---

Envoyé par cinemania

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 ...

Citation:

---

Envoyé par cinemania

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 :)

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...

Citation:

---

Envoyé par anthyme

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.

Citation:

---

Envoyé par 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)

---

Pas grave ;)

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

Citation:

---

Envoyé par cinemania

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 ?

Citation:

---

Envoyé par cinemania

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 :)

Dans WCF la seule chose dont l'appli cliente à besoin... c'est un lien vers la DDL common, où sont défini les Service Contracts (interface implanté par le webservice) et les Data Contracts (typiquement les BO manipulé par l'application)

L'implantation des classes d'adapteur qui implante le webservice doit etre dans une dll séparée qui sera hébergée par le serveur IIS ou dans une application hôte coté serveur.

Qui a dit que l'exemple fourni était forcément la seule et unique méthode ? WCF a des règles, il suffit de les respecter.
Tout dans le framework 3.0 et 3.5 est fait pour séparer les responsabilités, et bien ISOLER le code serveur du code cient, en ayant entre les deux que le moins de porosité possible. (dll avec uniquement interface et classes de données à sérialiser)
Nous somme bien d'accord en rvanche que ce niveau d'isolation était nettement plus floue avec des technologies comme .NET Remoting, ou pire encore...

Ensuite il y a des règles de bonnes programmations, qui vise comme dotnet3.0 a séparer les responsabilité quitte a multiplier les couches et interfaces entre les interlocuteurs, pour etre parfaitement sure qu'il n'y a que ce qui est strctement nécessaire qui franchisse la ligne de démarquation entre les deux mondes.
Le fait dans un client de faire appel a un webservice, si tu met comme dépendance la librairie commune, ne signifie pas que tu doive mettre comme dépendance le code du webservice... sinon, par exemple, l'utilisation de SQL Reporting Service serait fortement remise en cause.
WCF créé un canal de communication et génére un proxy qui implente l'interface dans la librairie commune.
maintenant c vrai faut décomposé ton programme c chinat c lourd... oui mais dans ce cas c'es tqu'il ne faut pas une simple appli N-Layers, mais N-Tiers.... ca oblige donc à multiplier les dll et exe.

okay !

Je regarde des screencast sur silverlight et je vois qu'on a les isolated storage donc je devrais pouvoir mettre en cache pas mal de trucs :)

Attention, l'isolated storage de Silverlight ne vous propose que 1 Mo par application....

ahhhhh c'était trop beau ...

économiser 1 mo de BP c'est pas la panacée...

pour en revenir au probleme des liaisons...

Le client doit juste avoir les liens vers le common pour les webservices et toute la gestion de l'UI.
en revanche l'utilisation de linktosql est a proscrire coté client. En effet, pour une question de sécurité et de la gestion des accès concurrent, tu ne devrais avoir ton code de gestion DAO (donc avc linqtosql) que coté Server.
la notion d'object mapping se fait coté DAO/BLL pas du coté client de la BOL.

C'est également vrai que la BOL est dans le common, l'interface de la BLL est exposée dans le webservice ou utilisée par le webservice, donc typiquement la BLL et la DAO sont coté serveur.