IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Dotnet Discussion :

[linq to SQL/WCF/Silverlight] Architecture


Sujet :

Dotnet

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre éprouvé Avatar de anthyme
    Homme Profil pro
    Inscrit en
    Mars 2004
    Messages
    1 559
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Mars 2004
    Messages : 1 559
    Par défaut [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

  2. #2
    Rédacteur
    Avatar de The_badger_man
    Profil pro
    Développeur .NET
    Inscrit en
    Janvier 2005
    Messages
    2 745
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Janvier 2005
    Messages : 2 745
    Par défaut
    Citation Envoyé par anthyme Voir le message
    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.
    Les règles du forum
    Le trio magique : FAQ + Cours + fonction rechercher
    Mes articles
    Pas de questions par messages privés svp

    Software is never finished, only abandoned.

  3. #3
    Membre Expert
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    1 103
    Détails du profil
    Informations personnelles :
    Âge : 47
    Localisation : France, Meurthe et Moselle (Lorraine)

    Informations forums :
    Inscription : Juillet 2006
    Messages : 1 103
    Par défaut
    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

  4. #4
    Membre éprouvé Avatar de anthyme
    Homme Profil pro
    Inscrit en
    Mars 2004
    Messages
    1 559
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Mars 2004
    Messages : 1 559
    Par défaut
    Citation Envoyé par The_badger_man Voir le message
    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 Voir le message
    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 Voir le message
    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 Voir le message
    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 ?

    Citation Envoyé par cinemania Voir le message
    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 Voir le message
    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 Voir le message
    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 Voir le message
    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 Voir le message
    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

  5. #5
    Membre Expert
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    1 103
    Détails du profil
    Informations personnelles :
    Âge : 47
    Localisation : France, Meurthe et Moselle (Lorraine)

    Informations forums :
    Inscription : Juillet 2006
    Messages : 1 103
    Par défaut
    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...

  6. #6
    Membre éprouvé Avatar de anthyme
    Homme Profil pro
    Inscrit en
    Mars 2004
    Messages
    1 559
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Mars 2004
    Messages : 1 559
    Par défaut
    Citation Envoyé par cinemania Voir le message
    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 Voir le message
    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 Voir le message
    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

  7. #7
    Rédacteur
    Avatar de The_badger_man
    Profil pro
    Développeur .NET
    Inscrit en
    Janvier 2005
    Messages
    2 745
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Janvier 2005
    Messages : 2 745
    Par défaut
    Citation Envoyé par anthyme Voir le message
    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.
    Les règles du forum
    Le trio magique : FAQ + Cours + fonction rechercher
    Mes articles
    Pas de questions par messages privés svp

    Software is never finished, only abandoned.

Discussions similaires

  1. WCF - LINQ TO SQL & IIS
    Par pas05 dans le forum Accès aux données
    Réponses: 1
    Dernier message: 02/12/2009, 20h10
  2. architecture multi couche avec Linq to SQL
    Par Henry9 dans le forum Débuter
    Réponses: 6
    Dernier message: 17/04/2009, 11h57
  3. [WCF/Linq To SQL] mise à jour
    Par matrix_ceg dans le forum C#
    Réponses: 5
    Dernier message: 20/02/2009, 15h33
  4. [Linq To Sql] Architecture en environement NTiers
    Par badack dans le forum Accès aux données
    Réponses: 0
    Dernier message: 15/01/2009, 13h00
  5. Linq to SQL et architecture n-Tier
    Par neptune dans le forum Framework .NET
    Réponses: 1
    Dernier message: 10/06/2008, 18h04

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo