J'ai fait la même remarque il y a peu, voici ce que m'a répondu Tomlev :Envoyé par iberserk
Du coup, j'en déduis que les deux sont utilisés...
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
Discussion :
J'ai fait la même remarque il y a peu, voici ce que m'a répondu Tomlev :
Du coup, j'en déduis que les deux sont utilisés...
One minute was enough, Tyler said, a person had to work hard for it, but a minute of perfection was worth the effort. A moment was the most you could ever expect from perfection.
-- Chuck Palahniuk, Fight Club, Chapter 3 --
Oui, oui, d'autant qu'en C# CamelCase est la convention (les majuscules ont beaucoup d'importance). Comme le nom de la procédure stockée est repris par Entity Data Model il vaut mieux respecter CamelCase. Un underscore dans le code est "interdit" dans la nomenclature.
"Winter is coming" (ma nouvelle page d'accueil)
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 :-))
Prendre conscience, c'est transformer le voile qui recouvre la lumière en miroir.
MCTS Database Development
MCTS Database Administration
+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...
One minute was enough, Tyler said, a person had to work hard for it, but a minute of perfection was worth the effort. A moment was the most you could ever expect from perfection.
-- Chuck Palahniuk, Fight Club, Chapter 3 --
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+
"Winter is coming" (ma nouvelle page d'accueil)
????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
Prendre conscience, c'est transformer le voile qui recouvre la lumière en miroir.
MCTS Database Development
MCTS Database Administration
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+
Prendre conscience, c'est transformer le voile qui recouvre la lumière en miroir.
MCTS Database Development
MCTS Database Administration
En mode troll:
D'ou l'utilité de prendre un ORM qui fera toujours la requête de la même facon!
J'ai bon?
Retrouvez moi sur :
Mon Espace Developpez.com-------------------------------
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...
+1En mode troll:
D'ou l'utilité de prendre un ORM qui fera toujours la requête de la même facon!
J'ai bon?
Autre doc: http://msdn.microsoft.com/en-us/libr...72(VS.71).aspx
"Winter is coming" (ma nouvelle page d'accueil)
Ah si ok
Bah alors, tout le monde est heureux!
"Winter is coming" (ma nouvelle page d'accueil)
Très intéressant! http://msdn.microsoft.com/fr-fr/netf.../hh237550.aspx
"Winter is coming" (ma nouvelle page d'accueil)
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);
One minute was enough, Tyler said, a person had to work hard for it, but a minute of perfection was worth the effort. A moment was the most you could ever expect from perfection.
-- Chuck Palahniuk, Fight Club, Chapter 3 --
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
Prendre conscience, c'est transformer le voile qui recouvre la lumière en miroir.
MCTS Database Development
MCTS Database Administration
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.
Prendre conscience, c'est transformer le voile qui recouvre la lumière en miroir.
MCTS Database Development
MCTS Database Administration
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'
Prendre conscience, c'est transformer le voile qui recouvre la lumière en miroir.
MCTS Database Development
MCTS Database Administration
Bouhouhouh personne lit mes post
"Winter is coming" (ma nouvelle page d'accueil)
Pardon
Prendre conscience, c'est transformer le voile qui recouvre la lumière en miroir.
MCTS Database Development
MCTS Database Administration
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
A+
"Winter is coming" (ma nouvelle page d'accueil)
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.
Répondre avec citation
Partager