Laden...

[erledigt] LINQ: vermeiden von anonymous Type ?

Erstellt von nose vor 11 Jahren Letzter Beitrag vor 11 Jahren 1.709 Views
N
nose Themenstarter:in
3 Beiträge seit 2012
vor 11 Jahren
[erledigt] LINQ: vermeiden von anonymous Type ?

verwendetes Datenbanksystem: <EF 4.0 mit LINQ>

Hallo,

ich habe folgendes Problem:

ich möchte in einer Methode ein IEnumerable zurückgeben, aber mein LINQ-Abfrage gibt einen anonymus type zurück, was dann natürlich nicht funktioniert.

Soweit ich verstanden habe, müsste ich dazu ein Klasse machen die als Properties alle Datentypen der Tabellenspalten darstellen muss. Diese könnten ich dann in der LINQ-Expression so verwenden:

select new MyClass{...}

In meiner Projektion mit select new selektieren ich alle Spalten der ersten Tabelle plus 2 Spalten aus der anderen. Das würde dann heißen, das ich so insgesamt 10 Properties in der MyClass anlegen muss mit den entsprechenden Datentypen - das finde ich irgendwie zu umständlich.

Gibt es nicht einen anderen Weg um das gleiche, aber ohne anonymus Type, zu erreichen?

Hier der Code denn ich habe:


public IEnumerable<Change> GetChanges()
{
var result = from c in _context.Changes
select new
{
c,
c.ChangeDefinition.Category,
c.ChangeDefinition.ChangeType
};

return result;
}

Gruß

Nose

5.941 Beiträge seit 2005
vor 11 Jahren

Hallo Nose

Nein das geht meines Wissens nicht anders.
Die äussere Klasse muss ja über den Typ Bescheid wissen und anonyme Typen sind nur lokal gültig.

Nutze also einfach eine neue Klasse.

Gruss Peter

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

771 Beiträge seit 2009
vor 11 Jahren

Hallo,

da du ja mit EF arbeitest, solltest du auch schon mal den Begriff POCO gehört haben.
Dafür gibt es dann auch einen Code-Generator: Entity Framework / Linq to Sql Poco Code Generator
Die daraus erzeugten Klassen kannst du ja dann als Kopiervorlage nehmen, falls du spezifische Klassen benötigst (z.B. aus JOINS).

P.S. Mittels


select new
{
  c,
  // ...
};

gibt du das EF-Objekt direkt weiter - du hättest also auch hier schon die Properties einzeln auflisten müssen (um EF-unabhängig die Daten weiter nach oben zu reichen).

16.834 Beiträge seit 2008
vor 11 Jahren

Sowas nennt man Projektion von Daten - und es ist ganz normal, dass man dafür auch extra Projektionsklassen erstellt.
Ganze POCOs zurück zu geben, wenn man nur 2-3 Properties braucht, ist absolut kontraproduktiv für die Performance.

Daher: leg Dir für Deine Abfragen extra Klassen an.
Das ist der saubere und korrekte Weg.

N
nose Themenstarter:in
3 Beiträge seit 2012
vor 11 Jahren

Hi an alle,

danke für eure Hinweise. Ich habe jetzt eine Klasse dafür gemacht mit den benötigenden Properties von beiden Tabellen und benutze diese nun für die Projektion - funktioniert nun wunderbar!

@Cat: ja ich benutze die POCO-Klassen. Das war ein guten Tipp, einfach von den generierten POCO-Klassen die Properties zu kopieren, das erspart Tipparbeit!

Also nochmal danke an alle!

Gruß

Nose

6.911 Beiträge seit 2009
vor 11 Jahren

Hallo nose,

das erspart Tipparbeit!

Da gibt es bei VS noch einen netten Tip: wenn die Klasse noch nicht existiert, schreib im Code-Editor den Klassennamen rein und klick dann mit der Maus auf den kleinen Balken (~Unterstrich) der erscheint. Für Eigenschaften dito. So kannst du dir die passende Klasse erstellen lassen.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

N
nose Themenstarter:in
3 Beiträge seit 2012
vor 11 Jahren

Hi gfoidl,

danke für den Tipp mit der Klassenerstellung. Für die Erstellung der Properties in VS schreibe ich ich immer prop oder propfull + 2 x TAB, das ist auch ganz nützlich.

Gruß

Nose