Et bien je ne suis pas daccord avec lui...
MICROSOFT, pour toucher les développeurs, tente d'instaurer le CAMEL CASE, et pourquoi?
Simple... c'est bien pratique quand on génère l'EDMX puisque celui-ci garde par défaut le nom des tables du coups "c'est pas bo ces classes en MAJUSCULE"... c'est tout...
De toute manière MICROSOFT n'a JAMAIS respecté les normes de nommage quand il s'agit d'intéragir avec .NET...
Bien avant LINQ, il fallait voir les SP et tables générées pour la gestion utilisateur/membership/profile/role intégrée ASP.NET!
Avec NVARCHAR et GUID au taquet en plus(sans débattre sur l'utilisation du GUID bien sûr :-))
+1 pour les GUID.
C'est pas tant l'utilisation de CamelCase dans les procédures stockées qui me gêne, c'est plus dans les index, keys, attributs de table, etc...
Grand troll en perspective.
Bon, pour info, en l’occurrence on parle aussi de PascalCase. Je suis pas trop à cheval là dessus. Perso, en fait, je "PascalCase" (Microsoft) tandis que d'autres "camelCase":
A vous de voir si vous préférez
- http://blogs.msdn.com/b/brada/archiv.../03/67024.aspx
- http://msdn.microsoft.com/en-us/libr...40(VS.80).aspx
ou
Code : Sélectionner tout - Visualiser dans une fenêtre à part db.SP_CREATE_CUSTOMER(obj.Id, obj.LastName, obj.FirstName);dans votre code.
Code : Sélectionner tout - Visualiser dans une fenêtre à part db.CreateCustomer(obj.Id, obj.LastName, obj.FirstName);
A+
????Grand troll en perspective.
OK... une des origines de cette convention est que :
- Certaines bases de données son en collation CS ou BINAIRE... d'ou l'utilité d'utiliser les MAJUSCULES...
- Celà limite l'écriture par des développeurs (ou DBA peu consciencieux...) de requètes avec des CASSES différentes, ce qui maximise l'utilisation du cache, en effet sachez que si vous faites
et
Code : Sélectionner tout - Visualiser dans une fenêtre à part SELECT NOM FROM MATABLEet bien vous forcez SQL SERVER à générer deux plans d'executions et à les mettre deux fois en cache...
Code : Sélectionner tout - Visualiser dans une fenêtre à part SELECT NOM FROM matable
Encore une fois je ne vois pas en quoi le fait de renommer votre SP dans votre DBML est compliqué si c'est ca qui vous gène???A vous de voir si vous préférez
db.SP_CREATE_CUSTOMER(obj.Id, obj.LastName, obj.FirstName);
ou
db.CreateCustomer(obj.Id, obj.LastName, obj.FirstName);dans votre code.
A+
C'est que parfois dans mon boulot cela a donné lieu à des disputes mémorables
Intéressant, je n'y avais jamais songé. Faut vraiment être DBA pour penser à tout ça!
Sinon, j'imagine que produire un tel document de convention est/était nécessaire parce qu'il n'y n'avait pas d'intellisens. Du coup, en mettant tout le monde en majuscules c'est plus pratique. Par contre, sachant que le renommage n'est pas aussi simple que sous Visual Studio, utilisez tout ces préfixes est un travail de dingue!
Je n'ai pas vu la possibilité d'ajouter des alias...
+1
Autre doc: http://msdn.microsoft.com/en-us/libr...72(VS.71).aspx
Très intéressant! http://msdn.microsoft.com/fr-fr/netf.../hh237550.aspx
Et pour info, Iberserk me corrigera si je me trompe, mais il me semble que le préfixe "SP" pour les procédures stockées devrait être réservé à la seule utilisation de Microsoft dans SQL Server. Les procédures stockées applicatives doivent être nommée différemment, par exemple
Code : Sélectionner tout - Visualiser dans une fenêtre à part db.SP_CREATE_CUSTOMER(obj.Id, obj.LastName, obj.FirstName);
Code : Sélectionner tout - Visualiser dans une fenêtre à part db.CODE_APPLI_CREATE_CUSTOMER(obj.Id, obj.LastName, obj.FirstName);
Nathanael :
Oui tout à fait...J'ai bon?
rien ne vous empeche de garder les conventions de nommage CHARP dans votre EDMX.... y compris pour les procédures stockées et fonctions tables (ne les oublions pas...).Et pour info, Iberserk me corrigera si je me trompe, mais il me semble que le préfixe "SP" pour les procédures stockées devrait être réservé à la seule utilisation de Microsoft dans SQL Server. Les procédures stockées applicatives doivent être nommée différemment, par exemple
Je vois que ça se discute pas mal.
Pour ma part je n'ai pas encore eu le temps ce week end pour me plonger dans le tuto.
Sinon pour ceux qui n'avaient pas assisté à l'après-midi du développement sur Entity Framework chez Microsoft je vous conseille de visionner le webcast ici.
ça parle de tout et même de l'optimisation des requêtes Linq To Entities dans la partie 9 du webcast et cette partie pourra intéresser plus d'un et c'est vraiement très instructif vu que la plupart du temps on se lance dans EF sans comprendre ce qui passe derrière.
Merci docteur
Je vais aller voir ca, je n'ai pas vu cette webcast.
Excellentes analyse 'pas besoin d'être un expert SQL pour savoir qu'ici il vaut mieu utiliser l'include: il génère 200000 requêtes sans'
Bonjour à tous !
L'article est trés trés interressant mais j'ai 2 ou 3 petites questions.
Au debut de la sortie de EF, j'ai voulu l'utilisé mais j'ai toujours trouvé des différences de performances par rapport à l'utilisation des Dataset ou des objets ADO.Net (SqlCommand ...). Les temps de chargement pour des petites tables était trés important, bien sur je ne connaissais pas cette techno et je me rend compte aujourd'hui qu'il existe de nombreuses possibilités d'optimisation. L'une d'elle est l'utilisation de procédures stockées, mais quand on a une base d'environ 50 tables, c'est fait tout de meme pas moins de 200 PS qu'il faut créer !!!
Mes questions :
- Utilisez vous des PS (CRUD) pour chaque table ou bien attaquez vous directement les tables ?
- Quelles sont vos optimisations sous EF ?
Salut,
Merci pour ton accueil de cet article
Il existe des générateurs de PS pour les opérations du CRUD.
Dans la mesure du possible, au regard des résultats, dans tous les cas, il vaut mieux faire des PS dès que c'est possible. C'est effectivement du travail. Cela peut donner des procédures comme: GetUsersByName, GetUserById, GetUsersByTown, etc. Tu peux aussi imaginer faire un UsersSelectAll au démarrage de l'application, mettre les données en cache et faire la recherche par le code. Tu gardes ainsi le jeu de données sur le serveur web et tu ne requêtes plus la base.
Si on retourne la question: dans quels cas une procédure stockée répond moins bien au besoin? Je dirais toutes les fois où la liste des champs ainsi que les clauses de la requête sont construites par le code. Ces cas là sont assez rares. Cela arrive dans le cas de moteur de recherche je dirais.
Finalement, j'utilise assez peu EF Les PS sont une bonne optimisation. Je te suggère de regarder le web cast deuxième lien dans les références: http://immobilis.developpez.com/tuto...amework/#LVIII. On peut en retenir une chose essentielle: ne demander à la base de données que ce dont on a réellement besoin.
A+
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager