Version imprimable
Salut,
Je viens de m'installer Visual Studio 2008, finalement plutôt que de faire migrer mon CMS à 2005 puis 2008, je vais faire directement le grand saut.
J'aimerais savoir si certains d'entre vous s'y sont déjà mis ?
D'avance merci pour vos réponses
++
Laurent
J'ai téléchargé la version Express pour le web et pour le C#.
Mais pas plus :D
J'ai migré quelques projets. Rien de transcendant. Je n'ai pas encore tiré partie des fonctionnalités 3.5, mais plutôt celles de VS 2008 (Profiler, etc).
Salut,
personnellement je m'intéresse qu'aux applications client-leger (il faut bien se spécialiser dans quelque chose) et en particulier aux applications AJAX communiquantes avec un Web Service, lui même connecté à une base de données.
Concernant link, je ne suis pas certain d'adhérer car je maîtrise suffisamment les procédure stockées pour ne pas avoir besoin d'une telle béquille...
Je crois que là ou il ont fait fort, c'est l'ajout de la fonction Web Service Reference qui permet de détecter automatiquement la partie web service d'une application web (le back end) et de créer toutes les classes automatiquement sur le site client (le Front end).
De toutes les façons, c'est tellement complet qu'à moins de travailler pour une grande administration (c'est à dire avoir pas mal de temps pour tout tester) il me paraît difficile de tout appréhender...
A suivre...
++
Laurent
Pas passé sous VS2008 encore la grosse nouveauté qui nous intéresse c'est LINQ mais comme cela ne fonctionne qu'avec Sql Server pour l'instant cela ne nous intéresse pas.
Salut,
Sur quelle base bosses-tu si ça n'est pas indiscret ?
++
Laurent
LINQ n'a pas pour but de remplacer les procédures stockées, que du contraire. Il s'agit de faire du mapping objets/relationnel. Tu peux utiliser des procédures stockées avec LINQ aussiCitation:
Envoyé par Laurent Jordi
Principalement sous informix et de plus en plus sous mysql.Citation:
Salut,
Sur quelle base bosses-tu si ça n'est pas indiscret ?
++
Laurent
Pour informix je ne m'attends pas a avoir une compatibilité avant un bon moment mais pour mysql on peut penser que dans qq mois cela sera bon.
Le problème est de générer la requête SQL correspondant à la requête LINQ. Ce SQL diffère fortement d'un système à l'autre.Citation:
Envoyé par npuzin
:mouarf:Citation:
Concernant link, je ne suis pas certain d'adhérer car je maîtrise suffisamment les procédure stockées pour ne pas avoir besoin d'une telle béquille...
merci d'avoir répondu Ditch. A t'entendre, laurent on a l'impression que pour toi, les SP c'est juste sortir les requetes en dur d'une BLL pour les mettre en base de données. Les SP servent à optimiser (précompilation de la requete) et surtout à avoir une sécurité grâce aux paramètres.
de l'autre côté, LINQ et ses dérivés pour base de données ou meme XML ou autre ont pour but de mieux architecturer et coder tes applis.
Si pour toi l'ORM est une béquille, il faudrait prévenir les adeptes du monde entier qui s'embetent à coder propre que leur appli est bancale :lol:
Hs: j'ai pas trouvé de tut link, dlink sur la page cours dotnet. j'ai mal cherché?:oops:
Euu non je fais quand même des procs un peu plus complexes que de simples select...
Pendant la démo link, j'ai demandé s'il était justement possible d'effectuer des traitements très complexes avec des jointures, des cas d'utilisation etc... Bien sûr ! m'a-t-on dit mais pas le temps...Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
Je pense que link est très bien mais compte tenu du fait que je travaille essentiellement du des SOA nécessitant une grande disponibilité, je préfère garder mes bonnes vielles procs qui, jusqu'à preuve du contraire, ont des performences innégalables...
++
Laurent
C'est sur que LINQ sera beaucoup moins performant que des SP, ca il n'y a meme pas a reflechir la dessus.
Par contre si tu recherches la souplesse, la facilité de maintenance, la rapidité de développement, la sécurité, etc LINQ est la pour ca.
Pour la performance a l'etat pur, il faut faire des SP.
Il me semble qu'il faut allier les deux car tu n'as pas toujours 200 connexions a la minute sur une page. Ou tu as des traitements qui seront deja suffisament rapide en utilisant LINQ.
Effectivement...
Je crois que linq sera bien adapté pour la gestion des back office des sites et des applications. En revanche pour les zonnes de consultation "intense" il faudra leur préférer les SP...
En tous les cas, je découvre les innombrables gadget de ide de VS2008... La split view et le système de gestion des styles c'est vraiement puissant... Domage que ça fonctionne encore avec des positionnement par table et non par div...
++
Laurent
Citation:
Envoyé par npuzin
Ah bon, quelle boule de cristal te permet de dire cela? C'est une grosse erreur de penser que c'est moins performant.
Je répète que l'objectif de LINQ n'est pas de remplacer les requêtes SQL ni les procédures stockées mais bien de faire du mapping en se basant sur ceci.
Par ailleurs, on a vite besoin de lier différentes sources de données et dans ce cas LINQ est plus approprié que tout autre chose.
Il existe bon nombre de webcasts très intéressants sur le net à ce sujet. Foncez et regardez les. Eviter de prendre les webcasts de base où on présente LINQ comme une nouvelle manière de travailler avec une base de données.
Ces webcasts amènent, c'est mon avis, plus de confusion qu'autre chose, cela se voit à la lecture de ce post. C'est une belle intro mais il est indispensable de regarder les autres webcasts pour avoir un avis objectif sur ce qu'est LINQ
Salut,
Passe les adresses de ces web cast...
Concernant l'homogénéisation je suis d'accord. Concernant les performances, il n'est pas nécessaire d'avoir une boule de cristal pour déduire que link le sera forcément moins (même si ça n'est pas de beaucoup).
Il y a des couches supplémentaires et, à moins d'utiliser des procédures stockées ou des vues comme source de données, impossible d'avoir accès à la compilation preemptive de SQL Server (Sauf si SQL Server 2008 offre un nouveau type de connecteur).
Notes que je peux me tromper, mais c'est comme ça que je le "pressens"...
++
Laurent
Non je n'ai pas besoin de boule de crystal pour deviner ca. Si tu veux de la performance, tu vas au plus court, tu tapes direct dans la base. Si tu veux de la souplesse, tu passes par un framework et ca n'est pas gratuit, ca te coute en temps de reponse.
Tu as le probleme avec n'importe quel framework de persistance comme hibernate par exemple, tu auras le probleme avec LINQ c'est une certitude, et Mitsuru Furuta l'a confirmé lors de sa derniere conférence LINQ.
Soit, je vais arrêter de discuter avec des gens bornés. Nous recommencerons cette discussion APRES que vous ayez regardé ce qu'était LINQ et les perfs.Citation:
Envoyé par npuzin
A nouveau si c'est pour faire un bête SELECT oui cela peut avoir un impact. Mais dès qu'on construit une application un peu plus structurée, il y a un apport.
Ceci dit il faut tout prendre en compte: création des objets, ouverture de la base, chargement des données dans un contrôle etc etc pour pouvoir comparer avec LINQ. Je ne suis pas certain que vous teniez compte de tout.
LJ: tu connais Google? :)
Euuhhh c'est pas un nombre avec plein de zéros ?Citation:
Envoyé par Ditch
D'ailleurs, je ne comprends même pas pourquoi tu poses cette question, c'est te dire à quel point mon niveau intelectuel est proche de celui du poulpe mort...
++
LJ
:king:Citation:
Envoyé par Laurent Jordi