Je construis un nouveau projet à partir de zéro. J'ai créé une DB où j'ai toujours appliqué une structure de dB que j'explique avec un exemple auto-explicatif court:
élément de table -> (ID, nom) -> contient des informations générales
Tableau > (Item_id, langue, description) -> Contient les informations dépendantes de la langue.
ID et élément_id sont connectés à une relation de clé étrangère.
Mon idée était de le modeler d'une manière Que je finirais d'utiliser seulement un seul objet POCO "élément" peuplé via le cadre d'entité. Cet objet ne contiendrait que les propriétés publiques: ID, nom et description. La langue sera cachée au code à l'aide de cet objet, l'objet lui-même devrait avoir la responsabilité de donner la description correcte en fonction d'une variable globale contenant la langue.
J'ai essayé de faire cela Et toujours fini par avoir des problèmes car l'entité cadre ne permettrait pas à ce scénario. J'ai toujours dû récupérer des informations pour toutes les langues et non seulement l'actuelle ou utilisez 2 requêtes différentes.
Donc, à la fin de la solution que j'ai commencé à utiliser était de laisser un modèle T4 créer à la fois un élément et un articleInfo et Ensuite, j'ai ajouté manuellement un code similaire à celui-ci: avec ce code J'ai ajouté les propriétés supplémentaires de l'élémentInfo à l'élément et sélectionné la langue correcte selon mes exigences.
Pensez-vous que c'est une bonne solution? Comment résoudriez-vous ce problème à la place? Cependant, exécutez SQL Profiler, je peux voir que 2 requêtes SQL différentes sont utilisées pour remplir l'objet d'élément, qui interroge la table d'élément et une autre qui intervient l'élémentInfo. < / p> peut être atteint le même scénario avec une seule requête qui fait une jointure entre les 2 tables? (J'ai peur de la performance à long terme frappé et c'est aussi comment je le ferais sans ormission). Toute suggestion sera la bienvenue, j'ai de nombreuses années d'expérience de programmation mais je suis un débutant avec Cadre d'entité et ormes en général. aide s'il vous plaît.
3 Réponses :
Je dirais que c'est une approche raisonnable. En outre, je ne m'inquiéterais pas des problèmes de performance avec deux sélectionneuses simples. S'il s'avère être un problème à l'avenir, vous pouvez le changer à une vue, par exemple.
+1 pour suggérer de ne pas s'inquiéter de performances prématurément. Optimiser le code s'il est effectivement trouvé comme un goulot d'étranglement. Très probablement, certains codes d'interface utilisateur quelque part seront le vrai coupable si votre application est lente.
C'est un goulot d'étranglement. Ceci est une réécriture d'une application existante et le goulot d'étranglement actuel est en effet la base de données. Il y a 15 tableaux avec cette structure, donc un total de 30. Le nombre de langues commencera également que les petites langues 3-4 mais pourraient augmenter, même pour atteindre 2 requêtes pour chaque fois qu'un élément est récupéré effectivement ralentira efficacement chaque charge de page où des articles Des tables différentes sont nécessaires et il sera très difficile de changer cela plus tard.
Si tel est effectivement le cas, alors je suggérerais la première méthode de Yakimych. Vous voudrez peut-être utiliser une classe d'enveloppe dactylographiée ( enveloppé ) au lieu du type anonyme et il suffit de le référencer partout au lieu de article lui-même.
Il y aura un problème de performance réel ici, car vous aurez besoin de N + 1 DB requêtes pour renseigner n'importe quelle liste. C'est (vraiment) mauvais et la fixation n'est pas une optimisation prématurée.
Vous pouvez essayer d'ajouter la clause WHERE de manière dynamique. Ou comme il a été dit, utilisez directement Linq vers SQL.
Comment ajouter une clause où ObjectSet d'un cadre d'entité
Ajoutez la clause WHERE DYNAMIELLE DANS UNE ENTTENSY Framework < / p>
Vous n'ayez pas montrant comment vous récupérez l'objet code> objet code>, mais généralement je ne vois pas de problème avec tout récupérer dans une requête. Vous avez plusieurs options. (ceci a été modifié pour utiliser Ceci renvoie une liste de tous les éléments ou vous pouvez l'extraire l'inverse (en commençant par
Vous pouvez faire une projection (mais pas sur une entité mappée - dans cet exemple, je projet sur un objet anonyme): sRevarArdefault au lieu de unique code> - voir la discussion de commentaires avec @craig stuuntz) em> p> code> - vous Peut ajouter un où code> clause pour filtrer. p> iteminfo code>): p> Item item = itemInfo.Item;
unique () échouera au moment de l'exécution de L2E. Vous devez utiliser singleefault () à la place.
@CRAIG STUNTZ - Cela dépend de la manière dont l'OP traitera des cas d'erreur, donc je n'imposerais donc pas que un seul est incorrect alors que SingleFault est juste. Ceci est également hors de portée de la question, mais vous avez un point ici bien sûr. Dans le premier exemple, je voudrais probablement que l'exception soit lancée, car n'ayant aucun ou plus d'une traduction dans la même langue est un état invalide. Dans le deuxième exemple, toutefois, je suis tout à fait d'accord - SingleEfault est plus préférable puisque nous essayons d'aller chercher un élément avec un identifiant spécifique et il pourrait ne pas exister. Édité le deuxième exemple, merci!
Je n'ai pas dit que single () était "faux". J'ai dit que ne sera pas exécuté dans une requête L2E. Jamais. Même s'il n'y a qu'une seule langue. L'as tu essayé?
@CRAIG STUNZZ - Oui, j'ai utilisé simple () dans les requêtes L2E, et cela fonctionne bien (au moins dans EF4). Existe-t-il un scénario spécifique qu'il ne fonctionnerait pas dans votre préoccupation?
@CRAIG Stuktz - OK, je viens de faire plus de tests et que vous aviez partiellement raison. Vous ne pourrez pas utiliser SIMOREFAULT soit, cependant. Voici l'exception que l'exception obtient: " Les méthodes" célibataire "et" célibataire "ne peuvent être utilisées que comme une opération de requête finale. Considérons en utilisant la méthode" FirstOdefault "dans cette instance. ". Donc, cela échouera effectivement dans le premier exemple. Édité pour utiliser FirstArdefault à la place, et merci encore.
Merci, j'aime les deux méthodes suggérées!
Pourquoi n'utilisez-vous pas LINQ-TO-SQL plutôt que d'utiliser le cadre d'entité?
En outre, je suppose qu'un article a de nombreux itemInfos?
LINQ to SQL est ancienne et sera obsolète Linq aux entités seront prises en charge depuis longtemps et est activement améliorée et développée évite à éviter que Linq soit possible si possible.