Hallo,
also in meiner Anwendung soll ich ein paar Termine (Ersteller, Zeitraum, Betreff usw.) in Form einer XML-Datei einlesen. Auf diese sollen dann auch Abfragen möglich sein. Allerdings nur von geringer Komplexität, also z.B. auf den Zeitraum, Ersteller usw.
Jetzt hab ich mich gefragt wie man sowas Strukturmäßig am besten aufbaut.
Das der Zugriff auf die XML-Datei in die Datenschicht kommt, ist sogar mir noch klar. 😉
Allerdings frag ich mich dann hier schon ob das besser mit ADO.net wäre (wegen den Abfragen) oder ich einfach die XML Datei durchlaufe.
Vorallem aber (und deshalb hab ichs auch hier reingestellt) bin ich mir absolut nicht sicher wie ich Daten intern repräsentieren soll. Also wie ich die Daten an die Geschäftsschicht liefere. Könnte ja für jeden Termine eine eigene Entität erstellen, ein DataSet mit den benötigten Terminen oder sogar ein typisiertes DataSet.
Würde also mal gern hören wie ihr sowas aufbauen würdet, welche Vorteile/Nachteile es gibt usw.
Gruß,
Snowwolf
Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden
Danke golohaas!
Das ist sehr ... erschlagend. 😁
Werds mir aber auf jedenfall mal genauer anschauen.
Lohnt sich ... wenn Du es durch hast und Interesse daran hast, wie eine Implementierung eines DAL mit eigendefinierten Objekten aussehen könnte, schau Dir mal svn://mywindowsserver.de/netug-kl.de an ... brauchst halt Subversion dafür.
Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden
Schade das MS XQuery noch nicht fertig hat, sonst würde ich dazu raten.
http://www.topxml.com/xquery/default.asp
http://aspnet.4guysfromrolla.com/articles/071603-1.aspx
http://aspnet.4guysfromrolla.com/articles/071603-1.2.aspx
Das W3C hat XQuery noch nicht fertig ... ich finde die Entscheidung von MS, mit der Integration in .NET bis zum endgültigen Standard zu warten, sehr positiv.
Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden
Der Ansatz über XQuery wäre sicherlich auch intressant, aber wenns eh nicht richtig implementiert ist brauch ich mir ja darum keine Gedanken machen.
Also das Dokument von MS hab ich jetzt mal durchgelesen und auf das Programm hab ich mir auch angeschaut. Danke dafür. Ist relativ hilfreich sowas mal umgesetzt zu sehen. Gib es dazu eigentlich auch irgendwelche UML Diagramme?
Ich denke ich werd die XML mit einen DataSet einlesen(gekapselt in einen Objekt der Data Access Logic) und dann an eine Geschäftsentität weiterleiten. An dieses Objekt kann man dann wiederrum abfragen stellen. Ich kann die Abfragen nicht in DAL legen, weil die XML relativ groß ist, auf einen Netzlaufwerk liegt und alle Objekte der DAL ja statuslos bleiben sollen. Also werd ichs in der Geschäftsentitätsobjekt zwischenspeichern.
Gruß,
Snowwolf
@golohaas.de
Das war jetzt nicht so gemeint, als wenn ich das nicht richtig finde,
sondern eher, das nachdem ich die o.g. Bibliotek schon vor einiger Zeit
gefunden und benutzt habe, und in den ersten Ankündigungen zum
FW 2.0 auch XQuery dabei war, ich es halt schade finde.
So müssen wir nocht ein wenig länger dadrauf warten.
Auf der anderen Seite benutze ich sowieso SQLite, das ist
"schneller" und einfacher, da ich SQL schon "kann".
Hallo!
So, ich greife mal den Thread hier etwas auf, da ich gerade vor genau diesem Problem stehe!
Gibts es neue Entwicklungen bezüglich dieser Thematik?
Ich hab mir den Guide von Microsoft überflogen, kann mich aber nicht entschliessen etwas zu nehmen, weil irgendwie alles mehr oder weniger große Nachteile hat (ich arbeite mit Instanz Daten, hab ich zwar noch nie gehört, müsst aber laut dem Guide passen):
*DataSets: viel zu viel Overhead
*Business Entities: geht nicht, weil wenn ich 2 Projekte mache (BusinessLayer und DataLayer), hat der BusinessLayer eine Referenz auf DL und umgekehrt: das lässt das VS nicht zu.
*XML: Zu viel Performance-Verlust wegen Parsen
*DataReaders: hm .. ziemlich komische Geschichte, DataReaders zurückzugeben, da sie ja Verbindungsgebunden sind.
*Scalar Values: keine Ahnung was man damit macht? Vielleicht kann mich wer von euch darüber aufklären?!
So, und demnach bin ich auf eine andere Lösung gestossen: Eine HashMap machen mit den Spaltenname als Key und Spalteninhalt als Value. Bei mehreren Ergebniszeilen halt ein Array von Hashmaps.
Frage: was haltet ihr von diesem "Umweg" und gäbe es da performancemäßig Probleme? Was nehmt ihr als Übergangsmedium zwischen DataLayer und BusinessLayer?
Ein paar Infos noch:
Vielen Dank schonmal im Vorraus für Tipps, Anregungen und sonstigen Beiträgen!
mfg DeveloperX
Original von DeveloperX
Business Entities: geht nicht, weil wenn ich 2 Projekte mache (BusinessLayer und DataLayer), hat der BusinessLayer eine Referenz auf DL und umgekehrt: das lässt das VS nicht zu.
Wieso hast Du dann zirkuläre referenzen? Dann hast Du was falsch verstanden ....
Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden
Also ich hab mir vor ca. einem Jahr einen eigenen DAL gebaut und hab damit absolut keine Probleme. Unabhängig der ganzen Artikel, die da im Internet rumschweben, muss man sich einfach nur folgende Gedanken machen:
Beispielsweise gibts da ja NHibernate. Gefällt mir persönlich überhaupt nicht, da zuviel Overhead, ausserdem benötige ich Dinge, die mir NHibernate einfach nicht anbietet.
Zu bauen ist ein DAL recht einfach - aufwändig wird nur die Erweiterung deselben.
Wenn man jedoch rein objekt-orientiert arbeitet, würden sich natürlich auch OODBMSen anbieten, also objektorientierte Datenbanken. Diese sind jedoch oft recht langsam und nicht sauber implementiert.
.NET GUI - Die Community für grafische Oberflächen unter .NET
Jetzt kostenlos besorgen: .NET BlogBook
Norbert Eder
DasBackup
Also ich hab für mein jetziges Projekt Codus (ist ein Code Generator) verwendet und mir damit die DAL aufbauen lassen. Einfacher kann eigentlich die Kommunikation mit der DB fast garnicht sein. Anderseits wenn dir sogar ein DataSet schon zuviel Overhead ist...
Original von Der Eisbär
Original von DeveloperX
Business Entities: geht nicht, weil wenn ich 2 Projekte mache (BusinessLayer und DataLayer), hat der BusinessLayer eine Referenz auf DL und umgekehrt: das lässt das VS nicht zu.Wieso hast Du dann zirkuläre referenzen? Dann hast Du was falsch verstanden ....
Weil ich dem DataLayer ja eine Klasse des BusinessLayers mitgeben muss (z.B. Contact). Der DL holt sich dann die Werte und speichert sie in die DB.
Und da der DL ja die Klassendefinition von z.B. Contact kennen muss, muss er ja auch eien Referenz auf BusinessLayer haben. Daher die zirkuläre Referenz.
Oder habe ich da etwas falsch verstanden?
Original von Snowwolf3000
Also ich hab für mein jetziges Projekt Codus (ist ein Code Generator) verwendet und mir damit die DAL aufbauen lassen. Einfacher kann eigentlich die Kommunikation mit der DB fast garnicht sein. Anderseits wenn dir sogar ein DataSet schon zuviel Overhead ist...
Ich will eigentlich keinen Code-Generator verwenden, da ich dabei ja was lernen will. Mir gehts im Prinzip nur darum möglichst viel selber zu machen und das auf die performanteste Art und Weise.
Was sagt ihr zu der Idee mit der HashMap?
mfg
Wenn du zirkuläre Referenzen hast solltest du die Definition der Klasse in eine Assembly ausladen, die von BL und DL referenziert wird.
Original von nitronic
Wenn man jedoch rein objekt-orientiert arbeitet, würden sich natürlich auch OODBMSen anbieten, also objektorientierte Datenbanken. Diese sind jedoch oft recht langsam und nicht sauber implementiert.
Woher hast du diese Informationen? Je nach Anwendungstyp können OODMS deutlich schneller sein als relationale DBs. Was die Stabilität angeht, würde ich mir an deiner Stelle mal Produkte anschauen, die schon eine gewisse Reife haben. Es gibt -auch für .NET - DBs, deren Engines haben mehr als 10 Jahre Produktionseinsatz auf dem Buckel. Ich hab vor ein paar Jahren ein großes System mit einem OODBMS umgesetzt. Das Ding läuft seit 5 Jahren im 24/7-Betrieb ohne jede DB-Wartung. Mach das mal mit Oracle & Co.....
Es gibt meines Erachtens nur wenige Gründe, die gegen den Einsatz von OODBMS sprechen:
* vorhandene Server-Landschaft. Gerade große Kunden versuchen homogene IT-Landschaften zu züchten, z.B. Oracle auf Solaris. Wenn du da mit einem OODBMS ankommst, kannst du gleich wieder gehen. Das gleiche passiert dir aber auch bei MSSQL unter Windows....
* Reportgeneratoren sind i.d.R. relational orientiert.
* keine Cluster-Möglichkeit, bei riesigen Datenmengen oder extremer Last ein Thema
Die Vorteile von OO-DBs sind klar: Deutlich weniger Entwicklungsaufwand, weil der DAL entfällt oder in Bruchteilen des Aufwands zu coden ist. Zudem braucht man keine "DB-Experten", weil die DB praktisch "unsichtbar" bleibt (mit Ausnahme von Transaktionen).
Im Prinzip ist es wie mit dem analogen Fernsehen. Es sprechen weniger technische Gründe dafür, sondern eher Bestandsargumente (Investitionen, vorhandenes Wissen, etc.).
Original von Der Eisbär
Lohnt sich ... wenn Du es durch hast und Interesse daran hast, wie eine Implementierung eines DAL mit eigendefinierten Objekten aussehen könnte, schau Dir mal svn://mywindowsserver.de/netug-kl.de an ... brauchst halt Subversion dafür. zwar schon ne ganze zeit lang her der post, aber hat jemand zufällig noch ein beispiel für so eine dal?