Kikuts
Messages postés159Date d'inscriptionjeudi 11 janvier 2007StatutMembreDernière intervention 5 novembre 2010
-
3 juin 2009 à 17:21
nhervagault
Messages postés6063Date d'inscriptiondimanche 13 avril 2003StatutMembreDernière intervention15 juillet 2011
-
4 juin 2009 à 21:34
Bonjour ! Alors voilà je suis en train de monter un Web Service pour que mes composants silverlight (xaml) puissent être "binder" ou bien récupérer des info à une base SQL Server.
Je me suis renseigné sur la façon de créer des requêtes, mapper une classe, exploiter la classe mappé avec le datacontext etc. ok c'est cool je peux faire pleins de choses. LINQ est puissant, permet de gagner du temps etc.
Mais où coder mes requête en LINQ ? Dans ma classe de Web Service ?
Désolé je suis litérallement perdu entre web service, LINQ, xaml, asp. Bref je commence à tout mélangé : /
Par ailleurs, est-ce utile de faire du LINQ to ENTITIES si ma base est une base SQL server ? Est-ce vraiment mieux ?
krimog
Messages postés1860Date d'inscriptionlundi 28 novembre 2005StatutMembreDernière intervention14 février 201549 4 juin 2009 à 11:31
Salut
"Ou il est mieux de créer un projet pour l'interface, et un autre pr la description des méthodes."
Une interface sert pour 2 choses : utiliser de la même manière 2 classes qui implémentent la même interface (les regrouper dans des listes, ce genre de choses) et définir le contrat qu'une classe, que ton programme ne connait pas, doit respecter, tout simplement parce que si ton programme connaît la classe, l'interface n'a aucun intérêt.
Pour résumer :
1ère utilisation
interface IVehicule
class Voiture : IVehicule
class Velo : IVehicule
List liste
liste[i].SeDeplacer(A, B);
Avec un webservice, tu es clairement dans le 2ème cas. Tu es censé avoir 3 projets :
- Un projet contenant uniquement l'interface (ou les interfaces) (une DLL bien sûr)
- Un projet web service qui référence ton projet d'interfaces et implémente celle(s)-ci, qui fait toutes les opérations, etc.
- Un projet client qui référence ton projet d'interfaces et qui fait une référence web vers ton webservices, qui appelle le web service pour créer un objet implémentant ton interface, et qui utilisera ta référence (du type de ton interface) pour faire les actions que tu souhaites sur ton web service.
Cela doit également répondre à ta question sur l'endroit où tu dois faire tes requêtes linq : directement dans ton webservice.
Krimog : while (!(succeed = try())) ;
- NON, "LE BAR" n'est PAS un langage de programmation ! -
krimog
Messages postés1860Date d'inscriptionlundi 28 novembre 2005StatutMembreDernière intervention14 février 201549 4 juin 2009 à 14:34
En gros (attention à de pas absolument tout prendre au pied de la lettre, je n'ai quasiment jamais touché à un web service, donc quelques erreurs ont pu se glisser),
Tu as ton projet client. Clic droit dessus => ajouter une référence => ta dll interface
C'est ce qui va te permettre d'utiliser (via une interface), l'objet renvoyé par ton web service
Clic droit sur ton projet => ajouter une référence de service => l'url de ton web service publié.
C'est ce qui va te permettre de renvoyer l'objet créé par le service.
Ton interface ressemble à ça
interface IHorairesDeCinema
{
public DateTime[] ChoperLesHorairesDuFilm(string film, string cinema);
}
Ton webservice ressemble à ça
[WebService blablabla]
public static class ObjectGetter
{
[WebMethod]
public static IHorairesDeCinema GetHorairesObject()
{
return new HorairesCine();
}
}
[WebService blablabla]
public class HorairesCine : IHorairesDeCinema
{
[WebMethod]
public DateTime[] ChoperLesHorairesDuFilm(string film, string cinema)
{ var q from h in maDB.Horaires.Include("Film").Include("Cinema") where h.Film.Name film && h.Cinema.Name == cinema
select h.Horaire;
return q.ToArray();
}
}
Ton client ressemble à ça
IHorairesDeCinema horaires = monWebService/*que tu as dû nommer au moment où tu as ajouté la référence de service*/.ObjectGetter.GetHorairesObject();
foreach(DateTime horaire in horaires.ChoperLesHorairesDuFilm("Terminator 18", "UGC Paris"))
{
Console.WriteLine("Le film passe le " + horaire.ToString());
}
L'avantage de faire cette méthode (qui passe par une interface) plutôt que d'utiliser directement un objet de type HorairesCine (dans mon exemple) est que tu peux changer autant que tu le souhaites ton webservice, tant que la classe implémente l'interface et que tu ne modifie pas cette interface, ton client marche sans avoir à faire la moindre modification / recompilation.
Krimog : while (!(succeed = try())) ;
- NON, "LE BAR" n'est PAS un langage de programmation ! -
nhervagault
Messages postés6063Date d'inscriptiondimanche 13 avril 2003StatutMembreDernière intervention15 juillet 201137 3 juin 2009 à 21:32
Salut,
Je vais tenter de répondre à tes questions.
1--> Linq2sql / Linq2Entities
Linq2sql fait un mapping rudimentaire entre la base et les objets (c'est a dire 1 table - 1 classe)
Linq2entities permet un mapping objet relationnel évoluer, c'est a dire que des tables peuvent etre splitté - pour représenter
des sous objets ou des heritage par exemple.
Le mapping est configurable de maniere tres précise.
NB Il semblerait que linq2sql serait abandonné par microsoft (a moins qu'il n'aurait plus d'évolution)
2 --> Structuration de projet
En général les web service WCF, sont a faire dans plusieurs projets
un projet qui expose les contrat des services web et un projet qui gere l'implementation
Kikuts
Messages postés159Date d'inscriptionjeudi 11 janvier 2007StatutMembreDernière intervention 5 novembre 2010 4 juin 2009 à 10:35
J'ai vu sur silverlight.net, sur un tuto vidéo, que le fichier monWCF et ImonWCF était directement intégré au projet de base, dans le dossier app_code.
Cela fait-il une grande différence ? Cela poserait il des problèmes d'utilisation ? Ou il est mieux de créer un projet pour l'interface, et un autre pr la description des méthodes.
Par ailleurs, si tu as regardé la vidéo du lien numéro 2/13, il y a une appli console. Est-ce utile ? Puis je l'intégrer dans une appli web pour tracer mes actions ?
Et avant de valider ta réponse, sais tu où est-il préférable de coder mes requête en LINQ ? Dans ma classe de Web Service ou ailleurs ?
Merci de ta réponse qui m'en a déjà pas mal dis. Je regarde en ce moment même les vidéos, très instructives, sur le web service (par contre je sais pas pourquoi, je ne peux pas me déplacer sur la vidéo, je suis obligé de recommencer la vidéo à zéro si je rate un petit bout ... et impossible d'ouvrir le lien des vidéos sous IE :(
Et sinon cool, maintenant je me pose des questions sur les Chanels et autres trucs vus dans la vidéo aye aye aye, j'en ai pas finit avec les web services ptdr
Désolé de poser bcp de question mais je suis curieux, (tqt pas je cherche aussi activement sur le net des vidéos et articles qui peuvent m'aider !) et tu me sembles bien renseigné sur le sujet. Donc autant demander à qq1 de compétent
Encore merci ; )
Vous n’avez pas trouvé la réponse que vous recherchez ?
Kikuts
Messages postés159Date d'inscriptionjeudi 11 janvier 2007StatutMembreDernière intervention 5 novembre 2010 4 juin 2009 à 12:05
Sacré Krimog <3 ^_^ merci ! pour le placement du code et le reste !!
>
- Un projet client qui référence ton projet d'interfaces et qui fait
une référence web vers ton webservices, qui appelle le web service pour
créer un objet implémentant ton interface, et qui utilisera ta
référence (du type de ton interface) pour faire les actions que tu
souhaites sur ton web service
J'ai du mal à comprendre ce bloc : ça ressemble à une phrase orienté objet mdr.
Je comprend pas trop : le projet client qui référence le projet interface et qui fait référence web vers le web service. Oula, j'essaye de faire un schéma sur papier, mais c'est pas très clair ...
Si tu pouvais me ré expliquer ce points (dsl j'aime pas être dans le flou)
Merci Krimooooooooog !!! (et les autres qui répondront hein ;)