Ist es möglich L&L direkt an einen Entity Framework context zu binden, sodass man vom context aus auf alle darunterliegenden Tabellen navigieren kann?
Also praktisch eine Lösung für EF die sich ähnlich verhält wie beim Beispiel zum ODataDataProvider?
Das Beispiel aus der Knowlegde-Base gemäss Knowledgebase - combit Reporting Forum ist für uns wenig hilfreich, wenn man immer nur eine Tabelle (inkl. div. Subtabellen) an den Designer übergeben kann, da sich unsere Reports u.U. über mehrere voneinander unabhängige Tabellen erstrecken können.
Zudem funktioniert das Beispiel nicht, da der System.Windows.Data.ObjectDataProvider keine Konstruktor-Parameter akzeptiert.
Mit freundlichen Grüssen,
Michael
ppreuschoff
(combit Support - Patrick Preuschoff)
2
Hallo Michael,
vielen Dank für Ihren Beitrag.
Ist das Verhalten auch nachvollziehbar, wenn Sie die von uns angebotene ObjectDataProvider-Klasse (combit.ListLabel21.DataProviders.ObjectDataProvider) verwenden?
Mit freundlichen Grüßen
Patrick Preuschoff
Technischer Support
combit GmbH
Vielen Dank für dei Antwort. Ja, mit der ObjectDataProvider-Klasse von L&L funktioniert es zwar, allerdings erhalte ich eine SystemOutOfMemory-Exception wenn ich den context direkt als Datenquelle verwende.
Das Objekt sollte nicht so riesig sein. Wenn dann ist das meine DB mit ca. 700 - 800 Tabellen.
Die Daten sollte er mir aber erst laden, wenn ich im Designer darauf zugreifen möchte.
Wenn ich die MaximumRecursionDepth auf 1 setze, dann erhalte ich beim Starten des Designers die Meldung dass Tabelle xy nicht gefunden wurde. Diese existiert dem Namen nach auch nicht auf der DB, aber auf dem context.
Das Problem habe ich dann übrigens auch mit dem ODataDataProvider. Erst Deadlock, dann SystemOutOfMemoryException. Dort setze ich dann auch expizit den Parameter “retrieveRealValuesForDesigner” auf false. Trotzdem schafft er nur eine maximale Aufruftiefe von 2.
Ich verwende das OData-Beispiel von combit, welches mit der L&L Trialversion ausgeliefert wird.
crauchfuss
(combit Support - Christian Rauchfuß)
7
Hallo Michael,
vielen Dank für Ihren Beitrag.
Die Daten müssen auch so schon geladen werden (zumindest 1 Zeile) um die Felder korrekt anzubieten. Mittels des HandleEnumerableProperty-Event des ObjectDataProviders können Sie dies sehr fein ansteuern.
Mit freundlichen Grüßen
Christian Rauchfuß
Technischer Support
combit GmbH
LL kann nicht wirklich mit dem EntityFramework umgehen.
Die Rekursionsbegrenzung ist zwar nett gedacht, allerdings wenig hilfreich, da man mal mehr und mal weniger Tiefe benötigt. Zudem kann eine unendliche Rekursion schon beim 2. oder 3. Level auftreten. Weiterhin gibt es beim mitgelieferten Provider Probleme mit komplexen Eigenschaften usw.
Wir haben uns einen eigenen “EntityObjectDataProvider” geschrieben, an dem wir explizit übergeben, welche Navigationseigenschaften verfolgt werden sollen. Und wir übergeben auch nur Objekte, die im aktuellen Anwendungsfall benötigt werden.
Das Schreiben eines eigenen Providers, der IDataProvider implementiert, ist zwar langwierig, lohnt sich aber, da man ihn genau auf seine eigenen Bedürfnisse anpassen kann.
genau dafür ist ja eigentlich das HandleEnumerableProperty da, damit kann man auf einzelner Property-Ebene entscheiden, ob man weiter iterieren will oder nicht. Wenn Sie daneben Interesse daran hätten, Ihren Provider zu teilen und vielleicht gemeinsam mit anderen Entwicklern weiterzuentwickeln: wir haben für solche Zwecke ein OpenSource-Projekt unter https://lldataproviders.codeplex.com/. Die LL-Community würde sich sicher freuen :).
Viele Grüße aus Konstanz und eine schöne Adventszeit rundrum,
