Hallo Frank,
> aber in Situationen, wo man bereits anonyme Typen hat, wäre ist es ggf. performancemäßig und vom Speicherverbrauch ggf. unangebracht, diese in stark typisierte List<T> zu überführen
Ich meinte stark typisierte List<T> statt anonyme Typen. Von Anfang an. Wo ich new { Problem=p.LastName } schreibe, kann ich doch gleich new PersonProblem { Problem=p.LastName } nehmen. Das wäre doch vom Speicherverbrauch vergleichbar,
und bei der Auswertung in Solve(IEnumerable<object>) würde die ganze Reflection bzw. das
casting by example entfallen, die man zum Umwandeln des anonymen Typs braucht, was der Performance auch nicht schaden würde.
Marcel schrieb: [...] zeigt wie anfällig die Arbeit mit anonymen Typen tatsächlich ist
Frank schrieb: Ich sehe das etwas weniger stark [...]. Anonyme Typen sind .NET Typen und quasi typsicher, und wenn man den einen in den anderen casten will, kommt saubererweise eine Exception.
Also ich habe folgende Probleme mit anonymen Typen, die über Methodengrenzen hinaus exportiert werden:
- Identitätsverlust: new {Problem="A"} ergibt den gleichen anonymen Typ wie new
{Problem="B"}. Bei stark typisierten Klassen ist jedoch ClassA.Problem durchaus was anderes als
ClassB.Problem (wenn zwischen den Klassen keine Vererbungsbeziehung existiert).
- Komplexe Differenziierung: In der Ziel-Methode, in meinem Beispiel
Solve(IEnumerable<object>), muss die Ablauflogik zwischen den einzelnen anonymen Typen als sinngebende Einheiten unterscheiden. Das schafft aber - angesichts der Tatsache, dass ich keine Kontrolle über den Namen der anonymen
Typen habe, und dass der RuntimeType für mich als Menschen nichtssagend ist - eine äußerst prekäre Situation. Nur Reflection und Hacks bringen mich da weiter, wenn ich auf die Member des anonymen Typen zugreifen möchte. Also
z.B.: Es ist kein if(v.GetType() == typeof(<>f__AnonymousType2`2)) möglich, da ich einfach nicht weiß, was <>f__AnonymousType2`2 ist. Ich kann ja alles über Reflection ermitteln: Parameter-Name, Parameter-Typ, Parameter-Wert
usw., aber eines nicht: Die genaue semantische Identität meines Typs (was bedeutet mir der Typ
<>f__AnonymousType2`2 vgl. mit Type PersonProblem?). Bleibt noch der Weg über try>cast>catch, aber auch dafür muss ich wissen was zu was ich caste, und die Performance...
- Schwere Wartbarkeit: Wenn ich die Methode ändere, die das IEnumerable<object> zurückgibt, muss ich immer den Consumer mit anpassen. Ich muss zusehen, dass sowohl Parameter-Namen, als auch -Typ und -Reihenfolge weiterhin
mit dem Code in der Methode synchron bleiben, die anonyme Typen zurückgibt. Das alles fängt leider kein Tool für mich ab, nicht der Compiler und nicht die statische Analyse.
Es gäbe noch weitere Probleme mit zurückgegebenen anonymen Typen, aber ich beschränke mich hier auf die für mich wichtigsten. Für mich sind anonyme Typen eben solange gut, wie ich sie nach dem Prinzip "set it, and forget it" verwenden
kann. Sobald es an die Wiederverwendung von anonymen Typen jenseits von Methodengrenzen geht, beginnt für mich der "Vespennest".
> man kann zum Beispiel auch folgende Ansätze oder Erweiterungsmethoden benutzen [...]
Auch RefactorPro mit dem ich gerne arbeite hat das von Dir erwähnte Refactoring (Name Anonymous Type). Leider hilft es nicht, wenn ich im Consumer-Code aus IEnumerable<object> wieder ein Typ hydrieren möchte. Die Erweiterungsmethode
aus dem codeproject-Artikel ist eine schöne Verpackung von Reflection-Code. In Deinem letzten Link fand ich dann das, woran auch ich fest glaube:
"You should consider to create the MyType objects already when you get the data, instead of creating anonymously typed objects."
Gruß
Marcel
