Hi Leute,

ich möchte ein etwas größeres Projekt programmieren. Ich bin grreeenhorn und weiss nicht genau wie ich es angehe. Also der Datenbankentwurf ( grober Art ) , d.h. nur die wichtigsten Relations die mir bisher eingefallen sind, steht soweit. Es geht um eine Simualtionsumgebung.

Jetzt sind die Fragen, ob man

- für jede der Tabellen auch eine Klasse einrichten sollte
- eine Datenbankverwaltung braucht ( Ich denke die Methoden gibts ja alle
schon, wieso braucht man dann eine eigene Klasse für die Database,
weil manche sagen es ist sinnvoll)

Für Tips wäre ich den Masters of the Compuserve

sehr zu Dank verpflichtet

Jack

Es kommt darauf an, wie du das Design gestalten willst.

Aber hier ein paar Punkte:

1. Eine Klasse pro Tabelle macht Sinn.

2. Datenbank-Zugriff (in welcher Form auch immer) sollte nur an einer einzigen Stelle passieren. Daher haben auch viele ihren eigenen Database Abstraction Layer (DAL) oder zumindest eine zentrale Klasse welche diese Aufgabe erledigt. Grund dafür liegt eindeutig in der Wartbarkeit und der Übersichtlichkeit.

3. Prinzipiell solltest du achten, dass gleicher Code nur einmal geschrieben wird. Das heißt, erstelle Klassen, UserControls etc. Dann gibts jeden Code nur einmal und hast dadurch wieder Vorteile beim Thema Wartung und Pflege.

4. Mach dich schlau zum Thema Patterns. Viele Probleme wurden bereits von anderen gelöst. Setze diese Patterns dort ein wo sie passen. Gutes Beispiel: Du baust dir eine Factory zum dynamischen instanzieren von Klassen. Hier würde sich das Pattern Singleton anbieten (wobei ebenso die Factory auch ein Pattern ist). Zur Erklärung: Patterns sind Muster, wie du bestimmte Probleme einfach lösen kannst.

5. Trenne auf jeden Fall die Business-Logik (also das was gemacht werden soll) von der Visualisierung (deinen Forms). Dadurch bleibt das Projekt immer schön übersichtlich.

6. Dinge die thematisch zusammengehören, gruppiere in Projekten, Namespaces, Klassen.

Tja, das wars mal erstmals Jetzt hast genug zum Suchen

Zitat von Norbert Eder

Es kommt darauf an, wie du das Design gestalten willst.

Aber hier ein paar Punkte:

1. Eine Klasse pro Tabelle macht Sinn.

2. Datenbank-Zugriff (in welcher Form auch immer) sollte nur an einer einzigen Stelle passieren. Daher haben auch viele ihren eigenen Database Abstraction Layer (DAL) oder zumindest eine zentrale Klasse welche diese Aufgabe erledigt. Grund dafür liegt eindeutig in der Wartbarkeit und der Übersichtlichkeit.

3. Prinzipiell solltest du achten, dass gleicher Code nur einmal geschrieben wird. Das heißt, erstelle Klassen, UserControls etc. Dann gibts jeden Code nur einmal und hast dadurch wieder Vorteile beim Thema Wartung und Pflege.

4. Mach dich schlau zum Thema Patterns. Viele Probleme wurden bereits von anderen gelöst. Setze diese Patterns dort ein wo sie passen. Gutes Beispiel: Du baust dir eine Factory zum dynamischen instanzieren von Klassen. Hier würde sich das Pattern Singleton anbieten (wobei ebenso die Factory auch ein Pattern ist). Zur Erklärung: Patterns sind Muster, wie du bestimmte Probleme einfach lösen kannst.

5. Trenne auf jeden Fall die Business-Logik (also das was gemacht werden soll) von der Visualisierung (deinen Forms). Dadurch bleibt das Projekt immer schön übersichtlich.

6. Dinge die thematisch zusammengehören, gruppiere in Projekten, Namespaces, Klassen.

Tja, das wars mal erstmals Jetzt hast genug zum Suchen

Hi, danke. Das war alles sehr nützlich, aber auch verwirrend für mich.

Eine Frage trotzdem noch:


Wie ist das mit der Klasse DB_Verwaltung. Ich habe eine Klasse erzeugt, die das connecten und disconnecten managed. Nun muß ich doch aber immer wieder diese Klasse instanzieren, folglich ist das Öffnen der Datenbank oder auch allgemein jeglicher Zugriff überall dort wo eine instanz im Code ist. Das wiederspricht aber deiner Aussage,das jeglicher Zugriff an einer einzigen Stelle passieren sollte? Oder verstehe ich as falsch?

Grüße Jack

Zitat von Kai_Jack

Nun muß ich doch aber immer wieder diese Klasse instanzieren, folglich ist das Öffnen der Datenbank oder auch allgemein jeglicher Zugriff überall dort wo eine instanz im Code ist. Das wiederspricht aber deiner Aussage,das jeglicher Zugriff an einer einzigen Stelle passieren sollte? Oder verstehe ich as falsch?

Ein bissel. Er meint Du sollst den Code für die Verbindung nicht überall einfach reinklatschen.
Stell Dir vor die Verbindung ändert sich. Ergo musst Du auch allen anderen Klassen aktualisieren.
Brauchst Du aber nicht wenn Du das in einer Klasse implementierst.
Wenn Du diese Klasse immer wieder instanzierst erzeugst das sowieso einen Overhead.
Versuch die Klasse überall verfügbar zu machen, nachdem sie instanziert wurde.
Das kannst via Referenz oder Interface lösen,
welche(s) Du deinen Klassen im Konstuktor oder via Property übergeben kannst.

@2.: Was zum Thema NHibernate O/R Mapper für .Net

MfG, cosmo

Dies ist meine Klasse. Was muß ich jetzt machen ( Referenz oder Interface ) kenne ich beides nicht genau. Und ist diese Klasse so brauchbar, also funktionieren tut der Code, aber ich glaube das ist nicht so das ware, oder ?

Code :

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

using System; using System.Data.SqlClient; using System.Windows.Forms; using System.Diagnostics;   public class DB_Management {     private System .Data.SqlClient.SqlConnection my_SQLConnection;       private string my_ConnectionString="Data Source=(local);Integrated Security=SSPI;"+"Initial Catalog=Test";         public DB_Management()     {     }     public bool Disconnect()     {         try         {             my_SQLConnection.Close();             my_SQLConnection=null;                                                  MessageBox.Show("Hallo, disconnected");             return(true);                                   }         catch( )         {                         return(false);         }     }     public bool Connect()     {         try         {             my_SQLConnection= new SqlConnection(my_ConnectionString);                         MessageBox.Show("Hallo, connected");             return(true);                                   }         catch( )         {             MessageBox.Show("Not connected");             return(false);         }     }     public System.Data.SqlClient.SqlConnection SQLConnection     {         get{return my_SQLConnection;}         set{my_SQLConnection=value;}     }   }

Danke den Masters of the Compuserve

Jack

Hast's also verstanden.

Der KlassenName und der Konstruktor stimmen nicht überein.
Definiere den ConnectionString als const um Speicher zu spaaren.
Wenn Du den Namespace eingebunden hast,
kannst Dir das ausschreiben des Namespaces beim deklarieren auch spaaren.

@Verfügbarkeit: Übergib sie als Referenz deinen anderen Klassen im Konstruktor.
Mit Interfaces kannst später anfangen.

Constructore e bene. Hab da was falsch kopiert, jetzt stimmt der Konstruktor wieder.

Habe aber ein Problem bei dieser Zeile:

SqlCommand comm = new SqlCommand("SELECT x_Koor, y_Koor FROM Point WHERE Point_ID=2",conn);

Der verlangt eine Connection, die ich Ihm aber nicht übergeben kann, da diese in der Klasse ist und er das so nicht akzeptiert. Was tun Also wenn man die Connection
SqlConnection m_SQLConnection public macht gehts. Aber das soll ja nicht sein,oder

Gruß und Dank Jack

Zitat von Kai_Jack

Der verlangt eine Connection, die ich Ihm aber nicht übergeben kann, da diese in der Klasse ist und er das so nicht akzeptiert.

Du hast doch ein Property DB_Management.SQLConnection dafür definiert.
Und wenn Du deine Klasse vom Typ DB_Management überall verfügbar machst,
kannst auch auf die Connection zugreifen.

Machs doch OOP gerecht und implementiere in deiner Klasse eine Funktion die Abfragt
und übergib ihr nur den QueryString.
Somit hast Du wieder alles sauber voneinander getrennt.

Kannst auch mal in diesen Thread schauen.
Da lernst ein bissel was über OOP.

MfG, cosmo

Es sieht aus als hättest du deine Klasse innerhalb einer Form. Ist das richtig? Wenn ja, ein eigenes Class-File erstellen und dort hinein.

Du kannst deine DB-Handling-Klasse als Singleton implementieren (im Google einfach nach Singleton suchen, ich mags jetzt net erklären), dann gibt es nur EINE Instanz deiner DB-Handling-Klasse und musst sie nicht neu instanzieren.

Die Connection musst du natürlich innerhalb deiner Klasse öffnen und schließen. Dann kannst du auch SQL-Statements absetzen, da du das Connection-Objekt ohnehin in deiner Klasse hast.

Zu deiner ursprünglichen Frage:
Es gibt unterschiedliche Möglichkeiten deine Daten zu persistieren bzw. unterschiedliche Ansätze (Patterns).
Dazu zählen zB Single Inheritance Mapping, Class Inheritance Mapping etc. Eventuell hast ja mal Lust und suchst danach, sollte im Google einiges zu finden sein. Da gibts noch einiges zu lernen.