Discussion :

[abbepierre94]

Bonjour à tous

Mon application est en Silverlight 3 avec Ria Services + Entity Framework et SQL 2008.

J'ai actuellement un script SQL assez complexe et long qui fait un tas de calculs à partir des données en base, et tout à la fin il retourne les variables calculées :

Code :

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

select @var1, @var2

Comment puis-je récupérer le résultat l'afficher dans ma page Silverlight ?
Je ne peux pas faire de vue (car ne peut contenir des calculs). J'ai pensé à une procédure stockée qui ferait les calculs et retournerait les 2 variables, mais je ne vois pas comment récupérer ça dans Silverlight.

Bref, j'ai cherché sans succès. Merci si vous avez une idée

[Invité]

Le plus simple pour toi serait de créer une procédure stockée puis de faire une importation de fonction sur la procédure stockée via Entity Framework. Une fois l'importation effectuée tu pourras exécuter cette fonction côté serveur (WCF par exemple) et renvoyer le résultat au client Silverlight.

[abbepierre94]

Merci bcp à toi h2. C'est intéressant, je ne connaissais pas. Suite à ta réponse, j'ai trouvé cet article qui explique la démarche :
http://blog.developpez.com/bdevuyst/...edure-functio/

Je suis sûr que ça fonctionne, seulement ça me pose problème. En effet, je suis en mode dév et je fais des modifs en base 10 fois par jour. Et à chaque fois j'efface puis regénère l'edmx (car le "Update model from database" ne fonctionne pas bien). Donc si je dois faire la manip de l'importation de fonction à chaque fois (pour peu qu'il y ait 50 manip car 50 fonctions), c'est embêtant.

Donc s'il y a une solution alternative, je suis preneur. Si non, je vais devoir me retaper tout mon script SQL en LINQ

[Invité]

Je suis sûr que ça fonctionne, seulement ça me pose problème. En effet, je suis en mode dév et je fais des modifs en base 10 fois par jour. Et à chaque fois j'efface puis regénère l'edmx (car le "Update model from database" ne fonctionne pas bien). Donc si je dois faire la manip de l'importation de fonction à chaque fois (pour peu qu'il y ait 50 manip car 50 fonctions), c'est embêtant.

Quelle est l'erreur qui t'est renvoyé en faisant un "Update model from database" ?

Concernant l'importation des fonctions, L'implémentation de la procédure peut changer autant fois que tu veux tant que le nombre et le nom des paramètres de ta procédure stockée n'ont pas changé alors c'est pas la peine de mettre à jour le model.

[abbepierre94]

Concernant l'importation des fonctions, L'implémentation de la procédure peut changer autant fois que tu veux tant que le nombre et le nom des paramètres de ta procédure stockée n'ont pas changé alors c'est pas la peine de mettre à jour le model.

Tout à fait d'accord. EF ne voit que les entrées/sorties, pas le contenu.

Quelle est l'erreur qui t'est renvoyé en faisant un "Update model from database" ?

En fait, je vais être un peu vague, mais des fois ça renvoit des erreurs, des fois pas, des fois ça fout la merde à l'exécution parce que ça a cassé des liens...
Si tu cherches sur Google "Update model from database bug", yen a tout plein.
Du coup on a reçu l'ordre de regénérer l'edmx quelque soit la modif en base

[Invité]

En fait, je vais être un peu vague, mais des fois ça renvoit des erreurs, des fois pas, des fois ça fout la merde à l'exécution parce que ça a cassé des liens...
Si tu cherches sur Google "Update model from database bug", yen a tout plein.
Du coup on a reçu l'ordre de regénérer l'edmx quelque soit la modif en base

C'est normal. Toute modification du schéma de la base de données (Relations entre tables, ajout de nouveaux champs obligatoires, suppression de tables etc) doit être suivie de la mise à jour du model EF sinon on risque d'avoir des surprises lors de l'exécution.

Une méthode plus simple est la suivante :
Si on est plusieurs à développer sur un projet utilisant EF, il faut choisir un développeur qui se chargera d'effectuer toutes les modifications nécessaires à la base de données même si c'est pas lui l'auteur de la modification et aussi c'est à lui que revient la mise à jour du model EF. Comme ça on diminue le risque d'avoir un model EF pas à jour.

[abbepierre94]

Oui justement, c'est moi le responsable de la mise à jour de EF. Et chaque fois je recrée l'edmx from scratch

Mais le problème reste entier. A chaque recréation (plusieurs fois par jour), je n'ai pas envie de refaire la "longue" manip d'import de fonction, multiplié par le nombre de fonctions...

Ou alors, est-il possible de requêter ma procédure stockée via un bon vieux SqlConnection / SqlCommand coté client, avec un WCF en face ? Je ne sais pas si c'est possible dans une appli Silverlight

Merci à toi en tout cas

[Nathanael Marchand]

Oui justement, c'est moi le responsable de la mise à jour de EF. Et chaque fois je recrée l'edmx from scratch

Mais le problème reste entier. A chaque recréation (plusieurs fois par jour), je n'ai pas envie de refaire la "longue" manip d'import de fonction, multiplié par le nombre de fonctions...

Ou alors, est-il possible de requêter ma procédure stockée via un bon vieux SqlConnection / SqlCommand coté client, avec un WCF en face ? Je ne sais pas si c'est possible dans une appli Silverlight

Merci à toi en tout cas

Euh? Ca peut être pas mal de prendre le temps de passer par la phase "Modélisation de l'application".
Une fois celle-ci terminée, y'a pu à toucher à la base de données.

[abbepierre94]

Euh... voui...
Effectivement on n'a pas de phase de modélisation, ya pas de specs, on développe tout au fil de l'eau. On n'a pas le choix, c'est le projet qui le veut snif.

Du coup, ma requête initiale n'aurait pas de solution, autre que d'effectuer des actions manuelles sur l'edmx ou de tout faire en Linq ?

[Invité]

Du coup, ma requête initiale n'aurait pas de solution, autre que d'effectuer des actions manuelles sur l'edmx ou de tout faire en Linq ?

tu voulais dire tout faire en "SQL traditionnelles" si cela te permet de gagner du temps. Mais moi je le ferais pas.

[abbepierre94]

tu voulais dire tout faire en "SQL traditionnelles" si cela te permet de gagner du temps. Mais moi je le ferais pas.

Ah non justement... j'ai déjà fait tous les calculs en SQL, mais impossible de rapatrier le résultat dans ma page Silverlight, avec les contraintes que j'impose (d'après tous nos échanges).
=> donc je pense devoir tout faire en Linq.

Code :

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

Mais moi je le ferais pas.

Pourquoi tu ne le ferais pas en SQL ? J'avoue je connais pas bien le Linq, mais ayant bcp pratiqué le SQL, on peut tout faire avec, et puis ça sert à ça, brasser les données.

[Invité]

Ah non justement... j'ai déjà fait tous les calculs en SQL, mais impossible de rapatrier le résultat dans ma page Silverlight, avec les contraintes que j'impose (d'après tous nos échanges).
=> donc je pense devoir tout faire en Linq.

Tu penses à Linq en oubliant qu'EF c'est du Linq To Entities . C'est pour ça que je croyais tu t'étais trompé et que tu voulais parler de SQL.

Pourquoi tu ne le ferais pas en SQL ?

Parce tout simplement c'est pas propre de coder en dur les requêtes SQL et ça devient vite chiant de trouver l'erreur quand il y a un bug.

J'avoue je connais pas bien le Linq, mais ayant bcp pratiqué le SQL, on peut tout faire avec, et puis ça sert à ça, brasser les données.

En parlant de Linq parles-tu de Linq To SQL parce que EF c'est aussi du Linq To Entities ?