Datenbankanwendung entwickeln - Konzeptionsfragen

Ich steh heute mal wieder mit ner ganzen Elefantenherde auf dem Schlauch. Irgendwie will passen mir meine eigenen Gedankengänge nicht.

Also Ziel wird sein. Eine kleine Datenbankanwendung für eine Oracle-Datenbank. Ein paar Formulare, ein paar Buttons und ein paar Views, Stored Procedures usw.

Mein geistiger Irrweg geht in die Richtung

Programm startet -> Datenbankverbindung wird aufgebaut, man tut dies und jenes, Programm schließen Datenbankverbindung zu machen.

Zusätzlich hab ich mich die letzten Paar stunden mit Singleton beschäftigt und ich denke mal es in diesem Zusammenhang zu nutzen wäre sinnvoll. Nur so ganz will mir das nicht in den Kopf und zwar wie man eine Singleton-Klasse richtig nutzt.
ich hab mich nach dieser Seite http://www.yoda.arachsys.com/csharp/singleton.html gerichtet (Version 2 -> mit lock)

aber jetzt zu den Verständnis/Verwendungsproblemen:

Soll ich ein Klassenattribut nutzen und beim Form_load die Datenbankklasseninstanz dieser zuweisen? Oder in jeder Methode Die Datenbankklasse instanzieren bzw die bestehende Instanz zuweisen?
Soll ich in der Datenbankklasse dann direkt im Konstruktor die Verbindung aufbauen?

oder bin ich mit dem ganzen total auf dem Holzweg und es geht anders besser?

im Grunde keine so schwierige Problematik, aber ich hab da nicht ganz den Durchblick

Ich würde die Verbindung immer dann aufbauen, wenn du sie brauchst. Eine stetig geöffnete Verbindung zur Datenbank erscheint mir nicht richtig.

Aber dazu können dir sicherlich kompetentere Leute wie FZelle helfen 😉

Grüße

Hi,

Datenbankverbindung immer nur dann aufmachen, wenn Du sie brauchst, .NET beherrscht ConnectonPooling und ist
darauf ausgelegt, dass die Verbindungen kurzlebig sind.

Mach Dir 3 Schichten:

• GUI
• BusinessLogic
• DataAccess

Zusätzlich würde ich mir eine Connectionklasse bauen, die die Verbindung zur DB herstellt, Commands (SPs, CRUD, VIEWS o.ä.)
absetzt und Dir Daten liefert.

In unseren Projekten haben wir im DataAccess den fachlichen DB Teil gelagert
(eine Schicht drunter der "richtige" Datenbankzugriff, manche nehmen die Schicht aber auch für die DB Operationen an sich.

Die BL holt sich die Daten über den DAL (DataAccess Layer) und reicht sie an die GUI
hoch.

Wenn Du möchtest kann Du die GUI noch mit einem MVC/MVP Pattern versehen, musst Du aber wissen.

Ein gutes Beispiel ist folgendes:
Rainbirds AppServer

Ich kann Dir nur folgende Entwicklungsunterstützung für Oracle empfehlen:
Oracle DA Components

So das war kurz umrissen meine Meinung/mein Wissen.

Naja, das ist wieder ein Beispiel, wo der Appserver definitiv überdimensioniert wäre.

Und die Aussage

Ein paar Formulare, ein paar Buttons und ein paar Views, Stored Procedures usw

bedeutet eigentlich auch, das hier eher aus ganz alten Welten heraus gedacht wird.

SP's sind zumindest für CRUD schon lange nicht mehr nötig, und die Gefahr durch
SP's die BL in den DB Server zu verlagern ist dann auch gegeben.

Ansonsten stimme ich DevHB zu.
Obs dann DataSet oder ORMapper wird als Datenzugriff ist dann eher nebensächlich.

Mach Dir 3 Schichten:

• GUI
• BusinessLogic
• DataAccess

öhm 🤔
sollte man das auch bei kleinen Projekten schon so machen oder ist es da eher mit Kanonen auf Spatzen geschossen?
Gibt es da zufällig was kleines Übeschaubares was GUI, BL und DA abbildet? Hab mich in der ganzen Sache wohl ziemlich überschätzt (was .NET Skill angeht), daher muss ich doch weiter vorne Anfangen.

Und die Aussage

Ein paar Formulare, ein paar Buttons und ein paar Views, Stored Procedures usw

bedeutet eigentlich auch, das hier eher aus ganz alten Welten heraus gedacht wird.

gut was mit alten Welten gemeint ist, kann ich nicht nachvollziehen. Die Beschreibung sollte lediglich aufzeigen, dass es im Grunde was ganz Simples werden soll. Wie ich so schön bewiesen hab, bin ich zur Zeit relativ leicht zu Überfordern

Im Nachhinein hätte ich vielleicht doch KFZ-Mechaniker werden sollen. Oder wenigstens bei PHP bleiben.

Salute st@tic

Schau mal hier:

• http://code-inside.de/blog/2008/07/09/howto-3-tier-3-schichten-architektur/

Gruss Peter

Hallo Static,

Programm startet -> Datenbankverbindung wird aufgebaut, man tut dies und jenes, Programm schließen Datenbankverbindung zu machen.

Das ist keine gute Idee, und auch nicht im Sinne des Erfinders von ADO.NET.

Schau hier :

[Artikel] Ressourcen schonen - Datenbanken richtig öffnen und schließen

und hier

Datenbanken richtig öffnen und schließen

Grüße Bernd

Hallo st@tic,

Mach Dir 3 Schichten:

• GUI
• BusinessLogic
• DataAccess

öhm 🤔
sollte man das auch bei kleinen Projekten schon so machen oder ist es da eher mit Kanonen auf Spatzen geschossen?

Ja, macht man auch bei den kleinsten aller Projekte. Ich würde sogar sofort 2-3 Assemblies anlegen, so dass die BL überhaupt keine Chance hat auf die UI zuzugreifen. (Das 3. Assembly nur, wenn ich keine generischen Datenzugriff, wie einen O/R Mapper habe).

Wenn du was ganz einfaches machen willst, dann solltest du dir eine Klasse aussuchen (z.B. CD), dazu die Datenbank-Tabelle, die BL-Klasse und eine UI schreiben.

Gruß
Juy Juka

[EDIT]
Angehängt findet sich jetzt ein kleines UML-Diagramm mit der Aufteilung von Klassen, Interfaces, Namespaces und Assemblies. Das sollte für einen Ersten groben Überblick hilfreich sein.

Die mir bekannten Knackpunkte und die Lösung dazu sind:

• Wie schreibe ich eine Datenschicht bzw. wie bekomme ich meine Daten in Objekte? => ADO.Net bzw. ein O/R Mapper (Da kann man hier im Datentechnologien-Forum bis zum erbrechen lesen.)
• Wie verwende ich Interfaces? => Factory-, Abstract Factory- oder Microkernel-Pattern
• Wie Bringe ich meine Daten in UI? => DataBinding
  [/EDIT]

danke für die ausführliche hilfe. ich denke, dass hilft mir etwas weiter. aber zum besseren verständnis hab ich noch ne frage

und zwar das 3 Schichtenmodel würde in meinem Fall (und meinem Verständnis) so funktionieren

Data Access Layer liefert mir meine Daten z.b. die meines Menüs (wird ne Treeview)
Business Layer holt sich quasi die Daten des DAL und bereitet die so auf, dass die
Präsentationsschicht nur noch darstellen brauch.

genauso umgekehrt. Ich mach was in der Gui (neuen Eintrag hinzufügen) die BL bereitet die Daten so auf, dass die DAL sie nur noch in die Datenbank oder sonstwas speichern muss.

Ist das vom Verständnis her korrekt?

und noch ne kleinigkeit. ich hab durch das ganze auch etwas mehr verständnis für interfaces erhalten aber noch ne kleine Frage hab ich noch

ich hab irgendwann jede menge methoden um irgendwas in der datenbank zu machen. wie mach ich das am besten mit der datenbankverbindung selbst?

das einzige was mir so einfällt
private connect und disconnect methode und in jeder methode dann am anfang der connectaufruf und am ende das disconnect

Hallo st@tic,

Zum Thema Datenbankconnection musst du nur kurz im Datentechnologie-Forum suchen.

Ansonsten kann ich deinen Aussagen zustimmen.

Gruß
Juy Juka

nach welchen stichworten? einfach nach datenbank und connect suchen? hab da manchmal bisschen schwierigkeiten was die wahl der suchbegriffe angeht 😁

Salute zusammen

Ist ja von Bernd (weiter oben) schon verlinkt, wenn ich mich nicht irre.

Gruss Peter

Hi static,

als ich von dem Schichtenmodell gehört habe, hat es mich aufgehalten, dass man immer ließt man solle drei Projekte anlegen und eins DAL, eins BL und eins PL nennen.
Das ist aus meiner Sicht, die falsche Angehensweise. Die drei Schichten würde ich eher als virtuelles(gedachtes) Konstrukt sehen. Es sollte eher in Zellen/Komponenten gedacht werden, die man geistig diesen Layern zuordnet.
Es gibt also mehrere Komponenten die z.B. auf die Datenbank zugreifen.(Vielleicht für jeden Entity-Typ(Person/Firma/Auftrag...) eine)

Zusätzlich zu diesen Schichten gibt es noch das Domain"modell". Dieses beschreibt sowohl die Daten, als auch die Funktionen, die direkt mit den Daten zusammenhängen.
Domainmodell - Funktionen(Da gabs doch auch ein Begriff dafür) = Datenmodell

Ob man diese(Daten und Funktionen), wie es eine streng objektorientierte Vorgehensweise eigentlich nahe legt, in eine "Komponente" packt oder man diese trennt bleibt dir überlassen.

Diese Datenkomponenten(Entities), werden von dem DatenaccessLayer zurückgegeben und vom Bussines Layer verarbeitet und von dem Presentation Layer dargestellt. Also stehen diese Datenkomponenten nicht direkt im Schichten Modell.

Ich hoffe ich konnte mich so schnell verständlich machen und habe nicht Kraut und Rüben durcheinandergebracht. Kritik erwünscht.

Auch das ist noch ein sehr stark vereinfachtes Modell und erhebt keinen Anspruch auf Vollständigkeit. *g

Gruß Timo

p.S. Um eine Anwendung wirklich komponentenorientiert und damit lose gekopelt aufzubauen, solltest du dich mit Microkernel und Contract First beschäftigen.

edit: hab einmal Klassen in den Klammern hinter Komponenten rausgenommen, da es zu falschen Schlüssen führen kann.

Hallo Timo

Dem wiederspreche ich, das aufteilen in mehrere Projekte macht / kann insofern viel Sinn, dass man die Projekte austauschen kann, bzw. die Layers.

Siehe auch mein erster Link (oben).
Und zum restlichen geschrieben kann ich zustimmen, siehe auch den Kommentar von Thomas Bandt im oben erwähnten Kommentar.

Gruss Peter

Achtung Missverständnis!!! *g

Ich will in mehr als 3 Projekte aufteilen!

Gruß Timo

Hallo Timo

Ich will in mehr als 3 Projekte aufteilen!

Wieso?

Gruss Peter

Hallo Peter,

ich bin der Meinung, dass es nicht wirklich zu einem "loosely coupled system" führt, wenn man alles in nur drei Projekte zwingen will.
Um praktische Sachen zu nennen:
Wenn man die komplette z.B. Data Access Logik in ein Projekt packt
-man hat immer mit riesen Projekten zu kämpfen
-werden Unit-Test schwerer zielgerichtet zu gestallten
-...
Und im Allgemeinen würde ich den Verlust an
-Reuse
-Wartbarkeit
-Übersichtlichkeit
-und so Zeugs(*g) nennen.

Ralf Westphal hat viel über komponentenorientierte Architektur in seinem Blog geschrieben: http://ralfw.blogspot.com/
Der hat das um Welten(Universums *g) besser vermittelt. Würde ich jedem empfehlen.

Gruß Timo

Hallo Timo

Jep klar, ich kenne das auch.
Ich dachte allerdings wir reden von einem 3-Schichten-System, darum meine Nachfrage.

Den Webcast zum Microkernel von Ralf ist sehr empfehlenswert, zu finden über den WebCast-Finder.
Aber den kennst du wohl schon 🙂

Gruss Peter

Hi Peter,

ich habe ziemlich gehangen, als ich mich damit beschäftigt habe. Da ich mir nicht vorstellen konnte, wie man die komplette Anwendung in nur 3 Assemblies packen kann.
Deswegen hab ich erklärt, dass dies Schichten sich nicht umbedingt in 3 Assemblies manifestieren müssen.
Außerdem würde ich den 3-Schichten Gedanken, nicht alleinstehend betrachten.

Gruß Timo

p.S. ja kenne ich auch schon, ich verschlinge zur Zeit alles was mir in die Hände fällt. 😉 Wer gute Bücher über komponentenbasiertes Development kennt, kann mir gerne eine Nachricht zukommen lassen(Wäre sehr nett).

Schau dir CAB/SCSF und Prism an ( beides auf Codeplex.com ).