Ich hatte einige Erfahrungen im ORM-Framework wie Hibernate, sogar Entity Framework 3.0.
Diese Frameworks verwenden standardmäßig den singulären Namen für die Tabelle. Zum Beispiel wird die Klasse Benutzer der Tabelle Benutzer zugeordnet.
Wenn ich jedoch mithilfe von Visual Studio 2012 zu EF 5.x migriere, wird der Pluralname verwendet, und viele Fehler werden verursacht, es sei denn, ich mappe diese Klasse manuell mithilfe von TableAttribute as:
Ohne TableAttribute , wenn ich ein DbContext wie folgt habe:
Dann rufend:
%Vor%Die generierte SQL sieht wie folgt aus:
%Vor%Daher tritt der Fehler auf, weil ich keine Tabelle mit dem Namen Benutzer habe. Außerdem verweise ich auf Namenstabellen in Singularform auf Pluralform. Sie können sehen, warum in dieser Link
Ich frage mich, warum Microsoft EF 5.x so implementiert und nicht EF 3.0?
Aktualisiert:
Wir können EF anweisen, den Pluralnamen nicht zu verwenden, indem wir diesen Code in der Kontextklasse verwenden:
%Vor%Auch wenn das EF-Werkzeug einen pluralisierten Namen generiert, sollte es die Zuordnungen zur ursprünglichen Datenbank beibehalten, oder? Weil einige Benutzer möglicherweise einige Namen von Feldern in ihrer Klasse ändern möchten. EF 3.0 funktioniert gut, aber EF 5.x nicht.
Jungs, können Sie mir bitte einen Grund geben?
Diese Konvention ist in der PluralizingTableNameConvention Konvention standardmäßig in DbModelBuilder.Conventions
Wenn Sie es von allen Tabellen ausschließen möchten, können Sie den Code aus diese Frage
Warum das so gemacht wird, weiß ich nicht, aber ich muss sagen, dass ich persönlich im Lager bin, das denkt, dass Tabellennamen pluraliert werden sollten:)
Von den Beispieldatenbanken, die mit einer SQL Server-Instanz bereitgestellt werden, hat Northwind Pluralformen, und AdventureWorks verwendet eine singuläre Form, sodass bestenfalls kein etablierter Standard existiert. Ich habe eine ganze Reihe von Diskussionen für oder gegen jeden gehabt, aber eine Sache, mit der sich alle einig sind, ist, dass, wenn Sie einmal eine Benennungsstrategie wählen, Sie dabei bleiben sollten.
Tags und Links c# entity-framework