2013-11-20 7 views
8

dieses einfache Modell Gegeben:Warum fügt Entity Framework in der WHERE-Klausel unnötige (AND [param] IS NOT NULL) hinzu?

public partial class UserColumnGrid 
    { 
     public int UserColumnGridID { get; set; } 
     public int UserID { get; set; } 
     public int ColumnGridID { get; set; } 
     public int ColumnWidth { get; set; } 
     public bool IsVisible { get; set; } 

     public virtual ColumnGrid ColumnGrid { get; set; } 
     public virtual User User { get; set; } 
    } 

Und diese einfache Abfrage: (userID ist ein int)

dbContext.UserColumnGrid.Where(ucg => ucg.UserID == userID).ToList(); 

Die folgende Abfrage generiert wird:

SELECT [Extent1].[UserColumnGridID] AS [UserColumnGridID], 
     [Extent1].[UserID]   AS [UserID], 
     [Extent1].[ColumnGridID]  AS [ColumnGridID], 
     [Extent1].[ColumnWidth]  AS [ColumnWidth], 
     [Extent1].[IsVisible]   AS [IsVisible] 
FROM [dbo].[UserColumnGrid] AS [Extent1] 
WHERE ([Extent1].[UserID] = 1 /* @p__linq__0 */) 
     AND (1 /* @p__linq__0 */ IS NOT NULL) 

Warum ist Dieses UND NOT NULL-Kriterium hinzugefügt? Die Datenbank lässt Nullen in diesem Feld nicht zu, und ein Int kann in NULL nicht null sein.

Dies passiert überall in meinen Abfragen. Es ist ziemlich nervig, aber beeinflusst es die Leistung?

Wie kann ich es loswerden?

Dies ist auf einem Datenbank-ersten Modell.

+0

Wie ist die erfasste Variable 'userID' definiert? –

+0

Es ist ein int an die Funktion übergeben, die diese Abfrage enthält: public void LoadUserSettings (int userID) –

+0

Ich nehme an, dass userid mit NOT NULL definiert ist oder wie PK ist dies so? – NoChance

Antwort

1

Ich habe die zusätzliche "(UND [param] IS NOT NULL) in WHERE-Klausel" durch Markierung der Eigenschaft in der Modellklasse, die mit Datenannotation erforderlich ist, los.

Ich benutze EF 6.

3

Natürlich würde es den Scheck machen. Denken Sie darüber nach, wie Entity Framework die Abfrage aus Ihrer LINQ-Anweisung erstellen muss. Es verwendet eine Menge Reflexion (wie in this SO question gezeigt), um die Arbeit zu erledigen. Daher bedeutet die Verwendung von Reflektion, dass Sie wahrscheinlich nicht die Zeit damit verbringen, darüber nachzudenken, welchen Typ ein bestimmtes Feld hat oder ob es nullfähig ist oder nicht - vor allem, weil es einfach die Null-Überprüfung hinzufügen und mit der Abfrage erledigt werden kann.

Meine Vermutung ist, dass dies absichtlich getan wurde, da die Verwendung von Reflektion, um den Typ zu erfassen und dann zu sehen, ob es NULL ist oder nicht, könnte ein großer Leistungstreffer sein - besonders für jede wirklich komplizierte Abfrage (wie eine mit vielen Parametern). Es ist vielleicht nicht notwendig, aber ich denke, es macht die Dinge viel einfacher für den täglichen Gebrauch.

+0

Wie wirkt sich dies auf den SQL Server aus? Es kommt mir einfach komisch vor, da ich in den letzten zwei Jahren hauptsächlich NHibernate benutzt habe und dieses Verhalten nicht hat. –

+1

Jede Auswirkung auf SQL wäre vernachlässigbar. Sobald die Abfrage erstellt und in SQL übertragen wurde, würde sie ziemlich schnell ausgeführt werden. Das Hinzufügen einer einfachen Klausel sollte keine großen Auswirkungen haben. Was NHibernate angeht, kenne ich deine persönlichen Erfahrungen nicht, aber ich habe es bei meinem ersten Job benutzt, gefolgt von EF bei meinem zweiten Job, und ich persönlich finde, dass EF den Job viel schneller erledigt als NHibernate. – IronMan84

+0

Danke. Ich fing eigentlich mit EF an, an dem großen Projekt, an dem ich arbeite, zu arbeiten, hatte aber zu viele Probleme damit (es war ziemlich neu) und entschied mich für den Wechsel zu NHibernate. Zwei Jahre später überlege ich, zu EF zurückzukehren, weil es jetzt ziemlich ausgereift und nett aussieht. –

Verwandte Themen