Laden...

DAL und Business/GUI Trennung mit einfachen Mitteln

Erstellt von orwell vor 14 Jahren Letzter Beitrag vor 14 Jahren 1.966 Views
O
orwell Themenstarter:in
12 Beiträge seit 2009
vor 14 Jahren
DAL und Business/GUI Trennung mit einfachen Mitteln

Hallo!

MVC, 3 Schichten-Architektur, Data Abstraction Layer, O/R-Mapper - das alles ist sicherlich sehr nützlich und hat auch eine große Fangemeinde.
Da ich gerade dabei bin, meine großen Pläne in Code umzusetzen, bin ich davon ausgegangen dass auch ich nicht um diese Themen drumrum komme und habe folglich die Forensuche bemüht.
Was mir auffiel: Neben Profifragen zu o.g. Themen gibt es auch immer wieder Threads von Anfängern, welche sich mit den Modellen und deren Anwendung schwer tun.

Doch gerade wenn es um die Trennung von GUI und Logik geht und Unerfahrene nach dem passenden Modell suchen, geben die Alteingesessenen hier im Board oft folgenden Rat (sinngemäß):

"Vergess MVC und Co. Jeder meint, man bräuchte irgendein mächtiges Modell für jede noch so kleine Anwendung, aber du schiesst ja auch nicht mit Kanonen auf Spatzen. Wenn deine Logikklassen die GUI-Member nicht kennen, dann ist das auch schon ein grundsolider Schritt".

Da war ich erstmal beruhigt und habe das auch so umgesetzt, sprich meine Logikklassen verwenden die GUI-Member (bzw. Usereingaben) nicht direkt, sondern akzeptieren diese höchstens per Parameter (obige Aussage ist doch so gemeint, oder?).

Jetzt habe ich das GUI also schonmal von der Logik befreit, und das auf eine einfache Weise, die man auch als Neuling versteht.
Das ganze fehlt jetzt aber noch in die andere Richtung, und zwar in Richtung Datenbank.
Gibt es in diese Richtung auch eine so einfache Abhilfe wie oben bei der Logik/GUI Trennung, oder komme ich jetzt nicht mehr so einfach davon?

Ich dachte da an eine einfache statische Klasse, welche als einzige aller Klassen eine Datenbankverbindung besitzt (die im Konstruktor aufgebaut wird) und dann Methoden bereitstellt wie z.B. addCustomer(int id, string name, string adress), welche dann von der Business-Schicht aufgerufen wird. Oder wäre diese Methode schon zu stark spezialisiert? Eine andere Idee wäre ebenfalls eine statische Klasse mit einer DB-Verbindung, welcher man nur einen SQL-Query-String übergibt und sich die Klasse dann um alles kümmert.

Vielleicht ist das zu naiv von mir, aber gerade denke ich, wenn ich wie oben das Wissen habe wie man Logik und GUI trennt und jetzt noch ein genauso einfaches System für die Datenabstraktion habe, dann habe ich ja eigentlich schon mein eigenes kleines 3-Schichten-Modell gebaut... oder etwa nicht?

Grüße

365 Beiträge seit 2007
vor 14 Jahren

Hallo....

Zur 3 Schichten-Architektur kann Ich jetzt nicht viel sagen, da gibt es hier im Forum kompetentere User.
Jedoch ist eine statische Verbindung keine gute bis schlechte Idee.
Solange du keine asynchrone Zugriffe auf deine Connection hast wirds wahrscheinlich keine Schwierigkeiten geben.
Aber sobald du Threads einsetzt die zufällig gleichzeitig auf die Connection zugreifen hast du den Salat. 😁

Connections erzeugen, öffnen und so schnell wie es geht wieder schliessen.
Am Besten in einen Using Block damit.

Ich wüsste aber nichts was gegen statischen Methoden spricht die deine Datenbankzugriffe und die Rückgaben kapseln.

Greetz da kubi.

5.742 Beiträge seit 2007
vor 14 Jahren

Hallo orwell,

Vergess MVC und Co. Jeder meint, man bräuchte irgendein mächtiges Modell für jede noch so kleine Anwendung, aber du schiesst ja auch nicht mit Kanonen auf Spatzen. Wenn deine Logikklassen die GUI-Member nicht kennen, dann ist das auch schon ein grundsolider Schritt

Nun ja - ich teile diese Auffassung nicht 100%ig.
Was MVC angeht, stimme ich durchaus zu - da stört das bisschen - es darf eben wirklich nicht zu viel werden - Code (unter WinForms wohlgemerkt) in der Codebehind eher nicht.

Zwar gibt es durchaus Projekte, bei denen auch der Einsatz anderer Pattern nicht sinnvoll da übertrieben wäre. Meines Erachtens sind das dann aber solche, die an maximal einem Tag geschrieben werden (und dann nie wieder angerührt werden).

Gerade wenn man seinen Programmierstil / "Entwicklerstil" verbessern möchte, kommt man IMHO nicht darum herum, möglichst gute Architekturen auch für kleine Projekte zu entwickeln.
Als Hobbyentwickler kann man es sich auch gut leisten, nach einigen Wochen Arbeit hinzugehen, um alles (mit einem deutlich besseren Ansatz) von Grund auf neu zu schreiben.

Wenn man "dann alles kann" 😉 ist man meist auch besser in der Lage zu beurteilen, wann sich der Einsatz von gewissen Pattern tatsächlich rentiert.

Wohlgemerkt sollte man dann aber die "Phase" erreicht haben, in der Architektur wirklich Spaß macht. Es bringt nichts, sich selbst zum Einsatz von Pattern zu zwingen, obwohl man sich davon überfordert sieht und nur Nachteile erkennt.
Diese Einstellung sollte sich mit der Zeit von selbst ändern.

sprich meine Logikklassen verwenden die GUI-Member (bzw. Usereingaben) nicht direkt, sondern akzeptieren diese höchstens per Parameter (obige Aussage ist doch so gemeint, oder?).

Nein!!!
Nicht kennen heißt nicht kennen. Weder als Properies noch als Parameter.
Die Logikklassen müssen auch ohne GUI voll funktionsfähig sein.

Jetzt habe ich das GUI also schonmal von der Logik befreit

Dann solltest du auch noch die Logik von der GUI entkoppeln.

Ich dachte da an eine einfache statische Klasse, welche als einzige aller Klassen eine Datenbankverbindung besitzt (die im Konstruktor aufgebaut wird) und dann Methoden bereitstellt wie z.B. addCustomer(int id, string name, string adress), welche dann von der Business-Schicht aufgerufen wird.

Das geht schon mal in die richtige Richtung.
Normalerweise verwendet man aber keine statischen Klassen (höchstens Singletons), sondern durch Interfaces entkoppelte "normale" Klassen.
Darüber, was man dem DAL genau übergibt existieren sehr verschiedene Meinungen. Häufige Varianten sind DataSets, Dictionaries und Entities (also reine Datenklassen).
Gerade beim Einsatz von O/R Mappern verschwimmt häufig die Grenze von DAL und BusinessObjekten.

Eine andere Idee wäre ebenfalls eine statische Klasse mit einer DB-Verbindung, welcher man nur einen SQL-Query-String übergibt und sich die Klasse dann um alles kümmert.

Eher nicht - genau das machen ja eigentlich die ADO.NET Klassen.
Ein bisschen mehr sollten sie schon leisten.

C
24 Beiträge seit 2009
vor 14 Jahren

Ohne großartig auf die einzelnen Patterns einzugehen, solltest du dir immer vor Augen halten, dass beim Code Wartbarkeit und Flexiblität im Vordergrund stehen sollte.

Daher ist es wichtig, die einzelnen Programmschichten so zu designen, dass sie jederzeit ausgetauscht werden können, bzw. Änderungen in einer Schicht vorgenommen werden, ohne andere Programmteile zu beeinflussen. Das sollte aus winSharp93 Post schon hervorgegangen sein.

Daher solltest du auch deine Datenbankschnittstelle entsprechend designen oder auswählen.

Vom Prinzip her hast du über der Datenbank eine Schicht, die die Grundoperationen auf die Datenbank definiert. Sofern du LINQ to SQL verwendest, kannst du deine Funktionen als stored Procedures schreiben, diese dann mittels Designer einbinden und eine Proxyklasse generieren lassen, auf die deine Business Layer aufsetzt und die Programmlogik bereitstellt. Wobei LINQ to SQL bei großen Datenmengen suboptimal, jedoch bei kleineren Projekten sehr hilfreich ist und die Schnittstellengenerierung/-erstellung vereinfacht.

Es gibt einen sehr interessanten Guide auf codeplex.com der sich mit dem Design von Anwendungen befasst. Ab dem Ende der 20sten Seite sollte es für deinem Fall interessant werden, bei dem es um das Design der Data Access Layer geht.

F
10.010 Beiträge seit 2004
vor 14 Jahren

@orwell:
Ich weiss garnicht, wo du hier soetwas gelesen hast.

Eigentlich wird hier immer das Gegenteil gesagt, also MVC/MVP/MVVM so früh wie
möglich einzusetzen, um eben nicht so wie Du jetzt vor dem Problem der evtl.
vorzunehmenden Architektur Änderung zu stehen.

Ansonsten ist es eine frage der Aufgabe, welche Art von DAL Du benötigst.
Wenn Du ADO.NET pur einsetzen willst, dann muss dein DAL die gesammte
SQL Generierung übernehmen.

ORMapper sind auch heutzutage nicht mehr so schwierig einzusetzen.
NHibernate kannst Du z.b. auch noch nachträglich über deine BusinessObjekte stülpen.

Erstellst du aber ein Repository für einen ORMapper, wird es etwas einfacher.
Mit FluentNHibernate, T4 und z.b. dem Linq2Sql designer kannst du da
sogar recht einfach etwas zusammenstellen.

Statische klassen sind aber das denkbar schlechteste, was Du hier bauen kannst.

O
orwell Themenstarter:in
12 Beiträge seit 2009
vor 14 Jahren

Ist wohl doch nicht so einfach wie ich mir das ausgemalt habe, aber mal der Reihe nach.

Aber sobald du Threads einsetzt die zufällig gleichzeitig auf die Connection zugreifen hast du den Salat.

Okay, leuchtet ein, schlechte Idee.

Gerade wenn man seinen Programmierstil / "Entwicklerstil" verbessern möchte, kommt man IMHO nicht darum herum, möglichst gute Architekturen auch für kleine Projekte zu entwickeln.

Nach euren Beiträgen hier werd ich das dann wohl auch in Angriff nehmen.

Nein!!!
Nicht kennen heißt nicht kennen. Weder als Properies noch als Parameter.
Die Logikklassen müssen auch ohne GUI voll funktionsfähig sein.

Eventuell hast du mich falsch verstanden, oder aber ich habs wirklich nicht begriffen.
Ich übergebe nicht die Referenz von einem kompletten GUI-Objekt, sondern nur den Inhalt des Text-Properties z.B.
Die Logikklassen sind ja so ohne GUI voll funktionsfähig. Eine Methode soll z.B. eine Usereingabe verarbeiten und erwartet als Parameter einen String. Ob ich nun in der Form den Text einer Textbox übergebe oder sonst einen String juckt die Methode ja nicht.

Es gibt einen sehr interessanten Guide auf codeplex.com der sich mit dem Design von Anwendungen befasst. Ab dem Ende der 20sten Seite sollte es für deinem Fall interessant werden, bei dem es um das Design der Data Access Layer geht.

Danke, vielleicht sollte ich dort gleich alles durchlesen 😉

Ich weiss garnicht, wo du hier soetwas gelesen hast.

Okay, ganz so war es vielleicht nicht formuliert, aber z.B. in diesem Thread kommt das so rüber: Trennung von Modell und GUI / MVC und 3-Schichten

Eigentlich wird hier immer das Gegenteil gesagt, also MVC/MVP/MVVM so früh wie
möglich einzusetzen, um eben nicht so wie Du jetzt vor dem Problem der evtl.
vorzunehmenden Architektur Änderung zu stehen.

Überredet. Aber da fängts schon an..

Habe über die Forensuche auch schon MVC-Threads gesucht, und in einem wird z.B. gesagt (als über ein Architekturproblem bei der Nutzung von MVC geredet wird), dass MVC schon sehr alt sei und eher für Konsolenprogramme gemacht wurde als für richtige GUIs.
Welches dieser Modelle würdest denn du vorschlagen, wenn die Komplexität noch überschaubar bleiben soll und es um Anwendungen geht, welche eine GUI bereistellen und auf eine Datenbank zugreifen? Ist da MVC die einzig wirklche Antwort? Gibt es ein "Multi-Purpose"-Modell?

MVVM scheint eher für WPF gedacht zu sein, das muss noch nicht sein, winforms reichen auch.

Am besten wäre ein Mini State-of-the-Art Projekt (also ne .sln), wo gezeigt wird wie man Daten von der GUI über Business laufend bis hin zur Datenbank schickt und der umgekehrte Weg, wie Daten über Business letztlich dann im Gui landen. Gibts so was?

Achja, ich weiß, dass MVC wiederrum aus anderen Mustern besteht und das die Sache verkompliziert, aber ein paar dieser "Submuster" kenne ich bereits.

Grüße

2.187 Beiträge seit 2005
vor 14 Jahren

Hallo orwell,

Bin mir bei meinem Post jetzt nicht ganz sicher, ob er nicht schon offtopic ist, lasse es jetzt aber erst mal normal.

MVC und "Submuster":
MVC ist eigentlich schon gar keine Entwurfsmuster mehr, sondern kann schon als Architektur-Stiel/Muster* gezählt werden. Da man alle Architektur-Stiele dann mit Entwurfsmustern umsetzt passt MVC hervorragend hinein.

Vielleicht kennst du den Thread schon, aber ich hab mir vor eine weile auch schon die selbe Frage gestellt wie du: Architektur/Pattern(s)/Framework für UI-Abkopplung

Gruß
Juy Juka

* Architektur-Stiel/Muster ist einfach größer und nicht so detailiert wie ein Entwurfsmuster

O
orwell Themenstarter:in
12 Beiträge seit 2009
vor 14 Jahren

Hallo JuyJuka,

nein, das ist keinesfalls offtopic, vielen Dank.

Nach den ganzen Antworten hier habe ich den Entschluss gefasst, mir also doch eines der großen Muster anzuschauen, von nix kommt nix 😉

Von einem Kollegen habe ich mir das Buch "Entwurfsmuster von Kopf bis Fuß" ausgeliehen, da darin ja auch MVC behandelt wird. Jetzt habe ich aber in deinem Thread gelesen, dass das der schlechte Teil am (ansonsten brauchbaren) Buch ist.. und ich bin mir unsicher, ob ich den MVC-Teil dann überhaupt lesen soll.

In deinem Thread bist du ja auch zu keinem endgültigen Entschluss gekommen (okay, mehr oder weniger schon), sondern zählst am Ende immernoch MVC, MVP und MVVM auf.
Eines davon will ich nun auswählen und mir versuche anzueignen (gut, einige werden aufgrund der Verwandtheit jetzt sagen, "kannste eines, kannste alle", aber zu komplex anfangen will ich nicht).

Fragt sich nur welches. Nach Recherchen hier im Forum bringt MVC bereits einige Nachteile im Bezug auf winforms (scheint eher für die Konsole gemacht worden zu sein), während MVVM zu WPF passt.

Fragen:

  • ist MVC wirklich zu altmodisch für "moderne" GUIs?
  • ist MVVM nur für WPF gedacht, oder kann ich damit auch gut die Konsole als GUI verwenden
  • MVP vielleicht ein gutes "Mittelding"?

Dann natürlich noch die Frage nach passender Literatur. Kommt man um ein Buch nicht rum, oder gibts auch etwas ausreichend ausführliches im Netz?

5.742 Beiträge seit 2007
vor 14 Jahren

Hallo orwell,

Eventuell hast du mich falsch verstanden, oder aber ich habs wirklich nicht begriffen.
Ich übergebe nicht die Referenz von einem kompletten GUI-Objekt, sondern nur den Inhalt des Text-Properties z.B.

Ja, dann habe ich dich falsch verstanden. Das ist durchaus so üblich - wie sollte man es auch sonst lösen 😉

ist MVVM nur für WPF gedacht, oder kann ich damit auch gut die Konsole als GUI verwenden

Na ja - ich sage es mal so: Man kann es in WinForms verwenden.
Wirklich glücklich wird man aber sicherlich nicht.

MVP vielleicht ein gutes "Mittelding"?

Mit MVP verhält es sich ähnlich wie mit MVC: Auch eher ein "Oberbegriff" für verschiedene Pattern.
Obwohl ich es nie wirklich verwendet habe, glaube ich doch, dass PassiveView (auf MVP basierend) das beste für WinForms Anwendungen ist.

F
10.010 Beiträge seit 2004
vor 14 Jahren

Naja, das ist Ansichtssache.

Ich benutze lieber den Supervising Controller, denn dann kann man dem UC
das binden, Anzeigen und bearbeiten der Daten überlassen, und den Presenter
dann nur über änderungen informieren.