Hallo inflames2k,

die Version für 2005 liegt unter folgenden Pfad: http://2005.invist.net/

Da ist das Verhalten allerdings noch etwas anders. Version 2.X ist eine komplette Neuentwicklung mit Konzepten, die sich in der Version für 2005 bewährt haben.

Das Laden und Speichern ist in beiden Versionen gleich. Allerdings ist Version 1.x wesentlich eingeschränkter und hat ein anderes UI.

UND: Version 2.x hat eine Testabdeckung von 100% im Framework, laut eingesetztem Tool.

Hallo TheGear,

ich kann mir gut vorstellen, dass Du das Gefühl hast, dass etwas nciht in Ordnung ist. Leider kann es teilweise sehr lange dauern. Das steht bei mir ganz oben auf der Liste, dass ich neben der Überprüfung des ConnectionStrings eine Anzeige einbaue, was gerade passiert.

Ich habe es sogar schon in einem Projekt erlebt, dass das auslesen 30 Minuten gedauert hat. Da bin ich auf das Problem aufmerksam geworden, dass an dieser Stelle ein Feedback kommen muss.

Auch wenn es hart klingt, hab etwas Geduld.

Reicht Dir die vorhandene nicht aus?

Ich bemühe mich die Doku so schlank wie möglich zu halten.

Okay, sie könnte etwas ausführlicher sein, aber was konkret fehlt Dir denn an Information?

Freut mich zu lesen, dass der Fehler gefunden wurde

Ich habe das ganze jetzt mal nachgestellt. Bei mir funktioniert alles wunderbar. Auch auf einem zweiten Rechner. Hast Du die Access geschlossen in der Zeit des Zugriffs?

Der ConnectionString läuft bei mir genau so, wie Du Ihn angegeben hast. Ich habe auf eine Access2003 Datei zugegriffen. Stellt sich die Frage, was bei Dir anders ist.

Wie bereits beschrieben, wird keine Zauberei im hintergrund durchgeführt. Solltest Du wirklich mit einer anderen Applikation zugreifen können, sollte es mit Invist auch gehen. Hast Du irgendwelche Benutzergruppen, oder sonstige Zugriffsrechte eingestellt?

Hallo,

mir fallen spontan zwei Punkte ein.

1. Hast Du als Datenbank auch Access ausgewählt?
2. Hast Du bereits in einer anderen Applikation den zugriff mit Deinem ConnectionString versucht?

Solltest Du mit einer ganz einfachen Applikation eine Verbindung zur Datenbank mit OleDB aufbauen können, dann sollte es auch mit Invist gehen. Zum Verbindungsaufbau benutzt Invist den OleDB Provider für den Verbindungsaufbau.

@MagicAndre1981,

einbauen kann ich es schon. Ich weiss nur nicht, wie weit er verbreitet ist. In welchen Bereichen wird denn Firebird eingesetzt? Ist nicht SQLite die am meisten verbreitet Freeware.

Um es kurz zu machen, Firebird ist natürlich interessant für mich. Ich weiss nur ncht, ob sich der Aufwand wirklich lohnt.

Ich kennen niemanden, der Firebird einsetzt. Aus diesem Grund betrachte ich Firebird-Unterstützung als nicht so wichtig an. Nenn mir [EDIT=herbivore]bitte per PM und nicht hier im Thread[/EDIT] mal ein paar Einsatzgebiete. Das könnte meine Meinung beeinflussen.

Version 2.2.0 von Invist ist released.

Hauptfeature ist das asynchrone laden und speichern von Daten. Realisiert wird dies durch die Verwendung des Async-Patterns. Das bedeutet, dass die Implememtierung Event-Gesteuert ist. Es ist somit kein komplizierter Methodenaufruf nötig oder diverse Delegates müssen implementiert werden.

Ein einfaches anmelden am Event reicht dabei völlig aus.

Die Roadmap für die zukunft liegt erst einmal auf der Anleitung, bevor es an Sachen wie LINQ oder eine bessere UI geht.

Hallo Counterfeit,

anregungen sind natürlich immer willkommen. Die UI lässt aus meiner Sicht mehrere Wünsche frei. Sie steht in meiner Roadmap auch für ein Redesign. Das werde ich wohl machen, wenn ich auf VS2010 umsteige. Zum jetzigen Zeitpunkt hat die Doku die höchste Priorität. Denn was nützt das beste Tool, wenn es nicht vernünftig dokumentiert ist.

In jedem Fall werde ich mir Deine Analyse genau ansehen. Viellicht kann ich das eine oder ander schon mal einfliessen lassen.

Vielen Dank für das Feedback. So etwas freut mich immer.

@Boonkez,

die Änderungen für MySql sind jetzt online.

@Boonkez,

das ist tatsächlich ein Bug. Das ist ein Problem mit den Berechtigungen. Ich hatte eine Änderung vorgenommen und mit einer Onlinedatenbank getestet. Alles wunderbar. Bei einer lokalen datenbank, warum auch immer habe ich das gleiche Problem wie Du.

Ich werde wohl beide varianten abdecken müssen. Das Problem was Du hast, ist jetzt eingebunden.

Da ich gerade an einer neuen Version baue, die das AsyncPattern unterstützt und somit das asynchrone laden und persistieren unterstützt, wird es wohl noch ein paar Tage dauern, bis ich das Problem mit MySql behoben habe.

Mein Anspruch ist jeden Bug mit einem UnitTest zu reproduzieren. Dieser Linie bleibe ich treu. Das Framework was innerhalb einer Applikation benutzt wird, hat eine testabdeckung von 100%. Das soll natürlich so bleiben. Bei der ermittlung der Metadaten bin ich noch nicht soweit mit meiner Testabdeckung. Aber ich arbeite dran. Deswegen möchte ich alles mit Tests abdecken.

Am besten Du geduldest Dich noch ein paar Tage und wartest, bis ich die neue Version hier ankündige oder Du schaust ab und zu mal auf der interseite von Invist nach.

Vielen Dank in jedem Fall für die Fehlermeldung.

Version 2.1.0 ist released. Kern der Version ist die unterstützung weitere Datenbanken

Es werden jetzt folgende Datenbanken unterstützt:

1. Microsoft SQL Server
2. Oracle
3. MySql
4. SQLite
5. VistaDB
6. Access

Zusätzlich als Information ist zu nennen, dass Invist das INotifyPropertyChanged Interface implementiert hat.

Ein eigener O/R Mapper macht aus meiner Sicht nur Sinn, wenn Wert auf etwas gelegt wird, was andere Mapper bisher nicht können, oder nicht ihren Fokus darauf gelegt haben.

Ich selber habe einen O/R Mapper geschrieben. Mein Fokus war etwas, was z.B. NHibernate nicht konnte. Ich wollte Code generieren und in die IDE integriert sein, mit einem vernüftigen UI.

Heute gibt es aus meiner Sicht genügend Mapper, dass es nicht nötig ist, einen weiteren zu entwicklen. Vor allem sind die meisten Mapper lizenzkostenfrei. Selbst Microsoft hat mit LINQ und dem Entity-Fraemwork etwas tolles entwickelt.

Du solltest vielleicht nicht die Zeit investieren, einen eigenen Mapper zu schreiben, sondern vielmehr vorhandene Mapper bewerten und die richtigen Einsatzgebiete herausfinden.

Wie sieht denn Deine Datenbank aus. Ich gehe jetzt mal davon aus, dass Die Tabellen genau so heisst wie Deine Klasse und jeden Property auch dem Namen der Spalten entsprechen.

Dir fehlt das Attribute "table" im class Node.

Hast Du es schon mal in Invist als Mapper probiert. Bietet sich an, falls Du eine exitierende Datenbank hast und daraus gerne die KLasse generieren möchtest.

Dann sollte das die Lösung sein. Wie die Exception sagt, wird die Funktionalität im CompactFramework nicht unterstützt.

Da würde ich ich der MSDN nochmal genau nachlesen, was das CompactFramework bietet.

In jedem Fall sagt die Fehlermeldung, dass es nicht unterstützt wird, weshalb es in der Desktop-Anwendung funktioniert und in der Anwendung mit CompactFramework eben nicht.

ZUr Not kannst Du es selber dserialisieren bzw. deserialisieren.

Wie sieht denn die GetNode Methode genau aus?

Ist die Klasse "EntryPoint" serialisierbar?

schau mal hier: http://dotnet.org.za/thea/archive/2005/02/22/14715.aspx

Für vereinfachten Datenzugriff hilft Dir vielleicht Invist als Datenzugriffsschicht weiter. Der Zugriff wird extrem vereinfacht. Es gibt auch Video Tutorials.

Mittels XPath kannst Du genau auf den Knoten springen, den Du suchst.

So wie cih das sehe, willst Du nur die ID des eingefügten Eintrages auslesen.

Das geht wesentlich eleganter. Du musst in der gleichen Transaction

SELECT @@Identity

ausführen.Der Returnwert ist dann die ID innerhalb der Transaction die in der Datenbank eingefügt wurde.

Die Installation wurde nochmal überarbeitet. Fehlende Rechte , sowie die Mindestanforderung von Visual Studio Standard werden während der Installation erkannt und gemeldet.

Nach über einem Jahr Arbeit ist die Version 2.0.0 endlich released. Invist hat ein komplettes Redesign erhalten und ist jetzt vollständig in Visual Studio integriert.

Invist setzt kein Datenbank-Design voraus. Unterstützt werden zum jetzigen Zeitpunkt SQL-Server, Oracle und MySql.

Zusätzlich wird eine komplett typsichere Filterung von Query auf die Datenbank unterstützt. Gewohnte Features wie z.B. PropertyChanged Events sind natürlich erhalten geblieben,

Voraussetznung für Invist sind:
Visual Studio 2008 Standard ( oder höher)
Administrationsrechte zum Installationszeitpunkt.

Ich denke das Problem kenne ich.

Ist das Tool vielleicht etwas für Dich?

Die Filterbedingungen sind flexibel.

Ich persönlich stehe mehr auf Attribute. Aber das ist ja jedem selber überlassen.

Aspect-orientierte Programmierrung setzt auch auf Attribute auf. Also können Attribute nicht schlecht sein. Schliesslich hat Java mit Annotations dieses Prinzip übernommen.

Es aber geschmackssache.

O/R Mapper ist nicht gleich O/R Mapper.

Grundsätzlich ist erst mal die Absicht eines Mappers zu beachten. Möchte man eine Klassenstruktur erstellen anhand einer Datenbank oder ist man doch eher auf dem Trip, dass man starke vererbungen möchte und daraus das Script für eine Datenbank generiert.

Das ist reine Geschmacksache.

Grundsätzlich findest Du eine ganz gute Erklärung bei Wikipedia.

Eine Liste von O/R Mappern findest du ebenfalls bei wikipedia: http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software

Solltest Du Visual Studio 2008 und das .NET Framework 3.5 im Einsatz haben, ist LINQ vielleicht ein Ansatzpunkt um sich in das Thema einzulesen. Dort wird vielleicht auch klar, dass man ohne SQL auskommt.

Der O/R Mapper der am weitesten verbreite ist nenn sich NHibernate. Bei CodeProject gibt es dazu eine gute Einleitung wie so etwas funktioniert.

Das Insert Statement und die Abfrage nach der Id MÜSSEN in der selben Transaktion ablaufen. Sonst klappt das ganze nicht.

Hallo,

natürlich ist so etwas grundsätzlich möglich. Beachten solltest Du nur, dass ASP.NET "stateless" ist.

Grundsätzlich nutze ich so etwas gar nicht.

Ich nutze Mocking Frameworks, wenn ich etwas ganz bestimmtes möchte.

Versuch es doch mal mit aspektorientierter Programmierung.

Das wäre zumindest ein Ansatz sich zu hooken. Ob das innerhalb des KOnstruktors funktioniert kann ich so allerdings nicht sagen.

Was willst Du den damit bezwecken? Soll der alte Knoten selektiert bleiben?

Warum nutzt Du nicht LINQ? Du kannst DEINE Klassen per Xml mappen.

Ich stimme FZelle zu.

So läuft es in meinem O/R-Mapper auch. Ansonsten würde ich von partiellen Klassen auch abraten, da sie das ganze nur verkomplizieren. Sollten man dennoch partielle Klassen einsetzen um eine bessere Übersicht zu bekommen stimmt etwas mit dem Klasendesign nicht.

Beispiel:

public class SuperKlasse
{
  public void GreateMethod(){...}
}

public class SubKlasse
{

  private readonly SuperKlasse superKlasse;

  public SubKlasse( SuperKlasse super ) {
     superKlasse = super;
  }

  public void GreateMethod(){
    superKlasse.GreateMethod();
  }

  public void EvenGreaterNewMethod(){
    // Implementiere Code
  }
}

Mit welcher Framework-Version arbeitest Du denn? Wenn Du 3.5 nutzt würde ich Dir ganz klar LINQ nahe legen. Das ganze kann man auch anpassen auf die eigenen bedürfnisse. Zumal die Syntax sehr einfach ist, wenn man sich mal dran gewöhnt hat.

Ansonsten würde das Rad nicht unbedingt neu erfinden. Es gibt so viele Gute O/R Mapper dass man nicht alles neu erfinden muss. Dre am weitesten verbreitete ist NHibernate.

Hallo um mal eine andere Möglichkeit ins Rennen zu werfen. Um auf das Grundproblem zu kommen. Es gibt ein DesignPattern, welches sich Decorator nennt. Es findet dabei keine Ableitung statt. Dabei wird die eigentliche Klasse als Parmeter in die zu erweiternde Klasse übergeben und als Member vorgehalten. Bei zugriff auf die Member auf die exitierende Klasse wird die Arbeit einfach weitergereicht. Die neue Funktionalität wird dann ensprechend Implementiert.

Um das ganze zu verdeutlichen schau mal bei DOFactory nach. Da ist das ganze wunderbar erklärt.

Hallo,

mir haben die Webcast von Microsoft geholfen das ganze zu verstehen.

Der Webcast den Du braucht ist über Databinding.

Webcast - Databinding

Da wird genau erklärt wie das ganze funktioniert. Mit Focus oder bei jeder änderung. Dauert ca. 1 Stunde.

Vielleicht wäre der richtige Ansatz nach transparenz zu suchen.

Ich würde Dir auch einen O/R Mapper empfehlen. Falls Du die Datenbankstruktur schon grösstenteils stehen hast, würde ich mal nach Code Generatoren suchen, die Dir die Klassen zu Deiner Struktur erstellen. Dann ersparst Du Dir eine Menge arbeit.

Das Problem, dass ein Projektmanager kommt und sagt: "Ich brauche eine weitere Information zu ...", kenne ich sehr gut.

Für solche Sachen setze ich einen Code Generator ein. Ich erweitere die Datenbanktabelle um das entsprechende Feld und generieren die Tabelle neu als .NET-Klasse.

Grundsätzlich lade ich immer alle Informationen einer Tabelle. Damit brauche ich auch nichts mehr anzupassenden, bei einem Update, oder insert, da alles mit generiert wird, oder dynamisch zusammengestzt wird. Es gibt also kein SQL innerhalb der Applikation.

Ich kann also nur O/R Mapper oder Code Generartoren empfehlen. Die Auswahl ist dabei sehr gross. Jeder hat seine Vor- und Nachteile. Du solltest Dich vielleicht etwas damit beschäftigen und schauen, welches Tool auf Deine Ansprüche passt.

Ich würde Dir eine eigene Klasse für Dein "Buch" empfehlen. Du könntest da eine DataSet kapseln was das speichern und laden aus der datenbank implementiert. Somit hast Du einen schnellen Datenbankzugriff aber auch alle Methoden, die Du benötigst für Dein "Buch".

Hallo,

schon mal an AOP ( Aspektorientiert progarmmierung ) gedacht. Ein mögliches Tool wäre PostSharp. Mit Hilfe von Attributen werden eigene Methoden aufgerufen. Du würdest Somit nicht die funktionalität der Klassen ändern sondern müsstes lediglich die Felder um ein entsprechendes Attribute erweitern.

Wenn Du z.B. Postsharp einsetzt wird der direkte zugriff auf das Feld durch einen Methodenaufruf ersetzt, der wiederum Deine eigene Methode aufruft. Das ganze passiert beim kompilieren, bzw. der Code wird dynamisch erweitert.

Wenn Du es richtig einsetzt hast Du sichergestellt, dass Du es nur einmal implementieren musst.

Ist C# für Dich neuland? Oder warum möchtest Du von vorne anfangen?

rizi hat in jedem REcht. System.IO ist der richtige Weg.

Schau Dir mal die Beispiele von DbCommand in der MSDN an.

Da ist die Datenbankunabhängigkeit durchdacht worden. Ob es einem gefällt,
wie es gelöst wurde ist eine andere Sache, aber es funktioniert.

Ich bin mir nicht ganz sicher, ob es eine Patentlösung gibt.

Grundsätzlich würde ich es folgendermassen machen ( oderhabe es sogar so gemacht),
dass Du deinem Object eine eigentschaft besitzt, die den Status wiedergibt. Dafür würde ich ein Enum hernehmen, mit den folgenden einträgen:
Created
Unchanged
Modifield
Deleted
...

Bei jedem setzen eines Properties prüfst Du ob es den Status unchanged hat und sich der Wert geändert hat. Ist dies der Fall, setzt du den Status von Unchanged auf Modifield.
Somit weisst du bei der persistierung, was Du mit dem Object machen musst.

Wenn Du mehr wissen möchtest schau doch mal unter Invist nach. Da wird mittels Code-Generator genau so etwas gemacht.

Hast Du Dir mal die Funktionalität eines Datasets genau durchgelesen? Ein typisiertes DataSet ist eine Ableitung eines DataSets. Soll heissen, wenn Du es hinbekommst, dass Du eine DataSet in der Datenbank aktualisieren kannst, dann klappt es auch mit dem typisierten, auf genau dem gleichen weg.

Wenn dass dan nicht geht, solltest Du Zeile für Zeile nochmal genau durchgehen. Irgendwo musst Du eine Abweichung haben.

Auch wenn die Klassenstruktur nicht so schön ist, würde ich persönlich dazu tendieren, bei Objekten, die die in einer Datenbank persistiert werden können nicht zu vererben. Egal was man mit den Objekten machne möchte, Hinzufügen, ändern ,oder löschen, es muss immer auf mehrere Tabellen zugegriffen werden. Ich würde diese Felder dann lieber redundant in den Datenbank-Tabellen speichern.

Bei kleineren Applikationen, wo die Vererbungshirarchie nicht so stark ist, ist dasn alles noch keine Problem, aber wenn die Vererbungs extrem gross wird, wird auf immer mehr Tabellen zugegriffen. Gerade bei aktualisierungen kann das dann schon etwas länger dauern. Das ist dann der Moment, wo O/R Mapper Ihre schwächen haben.

Sie haben dann zwar eine sehr schöne Struktur. Es lässt sich mit vernünftigen Objekten arbeiten, aber das schreiben der Daten dauert einfach zu lange.

Es sollte daher wohl überlegt sein, ob die Klassen, die die Informationen der Datenbanken verwalten sollen stark verschachtelt sind.

Hallo Razor,

um das ganze einmal von einer etwas anderen Seite zu durchleuchten, ob etwas als Singleton genutzt wird oder nicht.

Wenn, wie von Dir ursprünglich beschrieben eine CustomerManager-Klasse genutzt werden soll, diese allerdings bei der entsprechenden Methodenaufrufen immer das gleiche Ergebnis zurück geben soll, ist diese Klasse zustandslos. Es ist als völlig egal an welcher Stelle im System Sie genutzt wird. Die Methode GetCustomerOrders liefert immer das gleiche Ergebnis, solange keine Datensätze in der Datenbank geändert wurden.

Somit wäre Deine Klasse CustomerManager ein Service. Dies ist vergleichbar mit einem Webservice. Der Grundgedanke ist, dass egal wer eine Anfrage startet, die gleichen Ergebnisse geliefert werden. Dabei ist es egal ob Du oder ich eine Anfrage stellen. Wir würden beide das gleiche Ergebnis erhalten.

Es ist somit nicht notwendig, dass Du mehrere Instanzen Deiner CustomerManager-Klasse verwaltest. Ob du auf die Klassen ein Singleton-Pattern anwendest, oder nicht, ist dabei egal. Es ist in jedem Fall allerdings ratsam dafür zu sorgen, dass Es nur eine Instanz gibt.

FÜr den Aufbau des 3-Layer-Design ist es so, dass der UI-Layer definitiv nichst vom Data-LAyer weiss. Er kennt den Business-Layer und stellt dort seine Anfragen. Der Data-Layer wiederrum kennt auch nicht den Business-Layer. Der Data-Layer stellt nur die möglichkeit zur Verfügung, an Daten zu kommen und diese eventuell auch zu manipulieren.

Wenn Du die Applikation also sauber in drei schichten unterteilen möchtest Solltest Du siccher stellen, daass der UI-LAyer nur den Business-Layer kennt. Dieser aber nicht den UI-Layer.
Der Business-Layer kennt den Data-Layer, dieser aber wiederum nicht den Business-Layer.

Dem UI-Layer ist es somit völlig egal, wie der Business-Layer an die Daten kommt. Es ist nur wichtig, dass er die gewünschten Daten liefert. Dabei ist es uninteressant, ob die Daten aus der Datenbank, oder gar aus einem XML-File kommen.

Der Business-Layer interssiert sich ebensowenig dafür, wie die Daten von Data-Layer beschafft werden. Er weiss nur, bei wem er nach den Daten fragen muss ( Data-Layer) und verwendet die entsprechenden Schnittstellen des Data-Layers.

Der Data-Layer interessiert sich wiederrum nicht dafür, wer bei Ihm daten anfragt. Er stellt nur eine Schnittstelle zur Verfügung, die angesprochen werden kann um an Daten zu kommen.

Im Grunde lässt es sich ab besten so aufbauen, wenn Du eine Solution mit drei Projekten hast, wobei jeden Projekt einen Layer darstellt. Der UI-Layer bekommt eine Projektreferenz auf den Business-Layer, welcher wiederum einen Verweis auf das Data-Layer-Projekt hat. Solltest Du, aus welchen Grund auch immer einen Verweis des UI-Projektes auf das Data-Layer-Projekt benötigen, stimmt der Aufbau Deines 3-Layer-Design nicht.