MVC - Model-View-Control

Bitte ein Bit

Also ich finde es übertrieben, denn Software Engineering (vom dem das MVC stammt) ist kein Silber-Bunkett. Und daher gibt es immer Fälle, in denen gewisse Design Patterns/Ansätze nicht gut sind.

Auch objektorientiert gesehen gefällt mir der Code nicht. Denn die Namespace Bank besteht aus einer Factory, einer List und einem Model. Mach doch mal aus deinem Code ein Klassendiagramm und versuche mal einem anderen Unbeteiligten deinen Code zu erklären. Spätestens dort wirst du feststellen, was an dem Code nicht stimmt.

Aber nichtsdestotrotz ist der Code vielleicht ein schönes Beispiel, dass Design Pattern's sinnvoll eingesetzt werden sollte. Und vor allen Dingen zeigt dein Code, dass OO eine Stufe höher angesiedelt ist als die Implementierung. Denn einige Leute hier meinen, dass OO mit der Implementierung beginnt.

unskilled

Bitte ein Bit schrieb:

Auch objektorientiert gesehen gefällt mir der Code nicht. Denn die Namespace Bank besteht aus einer Factory, einer List und einem Model.

Hmm... Würd ich jetzt nicht wirklich sagen, dass das ein Nachteil ist... Es gehört ja auch alles dort hin und abgesehen von der List find ich auch alles extrem Verständlich für einen Außenstehenden... Aber für die List is mir nix besseres eingefallen ><

Bitte ein Bit schrieb:

Mach doch mal aus deinem Code ein Klassendiagramm und versuche mal einem anderen Unbeteiligten deinen Code zu erklären. Spätestens dort wirst du feststellen, was an dem Code nicht stimmt.

Also ehrlich gesagt find ich es nicht so schwer zu verstehen - nur halt nur mit Text (wie hier im Forum) etwas schwer, weils so viele (bis jz kleine) Dateien sind...

bb

Bitte ein Bit

Um es mal genauer zu sagen. Ich sehe die Bank als eigene Klasse an und nicht als ein Namespace.

Warum sollte man denn nicht eine Bank als Klasse realisieren wo doch eine Bank genau die notwendigen Eigenschaften dazu hat? Beispielsweise besteht ein Bank aus einer Menge von Accounts. Jede Bank kann Accounts hinzufügen oder entfernen. Kunden einer Bank besitzen einen solchen Account und können mit diesen Geld abheben...

Übrigens verwirrt mich die Model Klassen ein wenig. Denn was ist der Unterschied zwischen Bank::Model und Person::Model ? Kann man das Model einer Bank mit dem Model einer Person initialisieren ? Dumme Frage ich weis, aber nur so macht man sein Design dingfest.

Mir ist auch noch ein hübscher Desgin-Fehler aufgefallen. Du hast zwar eine Factory- und Singleton Pattern für deine Bank benutzt aber diese kann man sehr einfach umgehen weil der Konstruktor der Model-Klasse public ist.

unskilled

Bitte ein Bit schrieb:

Um es mal genauer zu sagen. Ich sehe die Bank als eigene Klasse an und nicht als ein Namespace.

Bitte ein Bit schrieb:

Warum sollte man denn nicht eine Bank als Klasse realisieren wo doch eine Bank genau die notwendigen Eigenschaften dazu hat? Beispielsweise besteht ein Bank aus einer Menge von Accounts. Jede Bank kann Accounts hinzufügen oder entfernen. Kunden einer Bank besitzen einen solchen Account und können mit diesen Geld abheben...

Und man hätte so eine Dreiecksbeziehung... Person wird gebraucht, um ein Konto zu erstellen - aber damit die Person Geld abheben kann, muss die Klasse Konto bekannt sein (na gut - in der Header-Datei ist es kein Prob, weil dort das Konto nur als forward-Deklaration reicht, aber ich finde trotzdem, dass es (unnötige) Abhängigkeiten erfordert).

Bitte ein Bit schrieb:

Übrigens verwirrt mich die Model Klassen ein wenig. Denn was ist der Unterschied zwischen Bank::Model und Person::Model ? Kann man das Model einer Bank mit dem Model einer Person initialisieren ? Dumme Frage ich weis, aber nur so macht man sein Design dingfest.

Bank::Model umfasst die Daten einer Bank (BLZ, vergebene Kontonummern und den zugehörigen Besitzer, nächste zu vergebende Kontonummern)

Person::Model umfasst die Daten einer Person (Name, vll noch Alter, ...) - ist also die Repräsentation einer Person - und in meinem Fall ist das dann der Kontobesitzer...

Nein, das Model einer Bank kann man nicht mit dem Model einer Person initialisieren, aber einen Account (ein Konto) muss man mit dem Model einer Person initialisieren...

Bitte ein Bit schrieb:

Mir ist auch noch ein hübscher Desgin-Fehler aufgefallen. Du hast zwar eine Factory- und Singleton Pattern für deine Bank benutzt aber diese kann man sehr einfach umgehen weil der Konstruktor der Model-Klasse public ist.

Jopp - ich weiß... War ja auch nur als Beispiel gemacht - hätte ich noch geändert, aber es war einfach nur mal nen Test, eine Klasse genau nach MVC zu bauen...

bb

witte

Wieso beerbst Du eigentlich List und Factory öffentlich von den Singleton-Schablonen? Das ist doch keine ist-ein-Beziehung sondern eher "ist implementiert als". Sollen die Singleton-Schnittstellen weiterhin zur Verfügung stehen?

asc

unskilled schrieb:

Bitte ein Bit schrieb:

Übrigens verwirrt mich die Model Klassen ein wenig. Denn was ist der Unterschied zwischen Bank::Model und Person::Model ?

Bank::Model umfasst die Daten einer Bank...
Person::Model umfasst die Daten einer Person...

Sobald man triviale Klassen erst beschreiben muss, ist zumindestens die Namenswahl schlecht (nicht selten auch das Design, wobei das eine nicht zwangsweise auch das andere bedeutet).

cu André

unskilled

witte schrieb:

Wieso beerbst Du eigentlich List und Factory öffentlich von den Singleton-Schablonen? Das ist doch keine ist-ein-Beziehung sondern eher "ist implementiert als". Sollen die Singleton-Schnittstellen weiterhin zur Verfügung stehen?

Weil ja Klassenname::GetInstance () gehen soll?!

asc schrieb:

unskilled schrieb:

Bitte ein Bit schrieb:

Übrigens verwirrt mich die Model Klassen ein wenig. Denn was ist der Unterschied zwischen Bank::Model und Person::Model ?

Bank::Model umfasst die Daten einer Bank...
Person::Model umfasst die Daten einer Person...

Sobald man triviale Klassen erst beschreiben muss, ist zumindestens die Namenswahl schlecht (nicht selten auch das Design, wobei das eine nicht zwangsweise auch das andere bedeutet).

Hmm... Ich war bisher nicht davon ausgegangen, dass man sie erst erklären muss?! Ist es nicht offensichtlich, dass die Klassen (nur) die Daten Kapseln? Ich meine:

Model - das Modell (mit meinem Verständiniss würde ich sagen, dass hier alle Daten anfallen, die die Klasse braucht - entsprechend mit Getter/Setter-Methoden)
View - die Ausgabe bzw Ansicht
Control - Funktionen, die das Model in irgend einer Art und Weise manipulieren?!

Also mal nen recht triviales Beispiel:

/*dummes_bsp.h*/
#include <string>
#include <iostream>

namespace Beispiel
{
 class Model
 {
  private:
   std::string data;
  public:
   Model (const std::string _data = "") : data (_data) {}
   std::string GetData () const {return data;}
   void SetData (const std::string &_data) {data = _data;}
 };

 namespace View
 {
  void WriteTo (std::ostream &s, const Model &data)
   {
    s << "bla: " << data.GetData () << std::endl;
   }
 };

 class Control
 {
  void Add (const Model &Source, Model &Dest)
   {
    Dest.SetData (Dest.GetData () + Source.GetData ());
   }
 };
}

#include "dummes_bsp.h"

int main ()
{
 const Beispiel::Model Hallo ("Hallo");
 const Beispiel::Model Welt ("Welt");
 const Beispiel::Model Leerzeichen (" ");

 Beispiel::Model Hallo_Welt;
 Beispiel::Control::Add (Hallo, Hallo_Welt);
 Beispiel::Control::Add (Leerzeichen, Hallo_Welt);
 Beispiel::Control::Add (Welt, Hallo_Welt);

 Beispiel::View::WriteTo (std::cout, Hallo_Welt); //Hallo Welt
}

asc

unskilled schrieb:

Hmm... Ich war bisher nicht davon ausgegangen, dass man sie erst erklären muss?! Ist es nicht offensichtlich, dass die Klassen (nur) die Daten Kapseln? Ich meine:

Mich interessiert bei der Namenswahl im ersten Moment nicht das Design. Ob man MVC verwendet oder nicht sollte IMHO nicht zu einer gänzlich anderen Namenswahl führen. Zumal du mit deiner Benennung bei der Reduzierung auf die drei Begriffe den Sinn von MVC eh ad absurdum führts.

Das Model sind die Daten, dies kann eine Klasse sein, dies können aber auch mehrere sein. Ich halte es für unsinnig für jedes Modell ein eigenen Namensraum zu schreiben. "Die" View gibt es nicht, das Sinn vom MVC ist ja gerade das es mehrere Views geben kann, hier ist also die Benennung View für sich alleine genommen schlecht, soll jede View nochmal einen eigenen Namensraum bekommen? (Okay, bei mir wär die "View" eh in einen anderen Namensraum, da ich UI (UserInterface) von BL (BusinessLogic) etc. trenne).

Ich würde es ja verstehen wenn du die Klasse BankModel genannt hättest, auch wenn ich mir darunter dennoch etwas anderes vorstelle ;). Das man die Oberfläche als solche auch irgendwie kenntlich macht, sehe ich ja auch ein - Aber versteif dich nicht zu sehr auf "Model", "View", "Control" als Klassennamen - ergänzend mag dies okay sein, für sich alleine ist es wenig sinnvoll.

Vielleicht mag ich dort alleine stehen, aber ich bennene die Klassen lieber so, das man sie - sofern möglich - umgangssprachlich verstehen kann. Kleines Beispiel gefällig? (Stark verkürzt)

Ich verwende als Hierachie für den Namensraum meiner Projekte eine folgende Struktur:
<Projektname>::<Modul/Bereich>::<Schicht>[::<Untergliederung>]

Bei den Schichten kann man sich durchaus auch streiten, ich verwende: UI für alles, das die Anzeige betrifft (Dies können Fenster ebenso wie einzelne Komponenten sein; View), BL für die Programm- und Geschäftslogik (sprich: z.B. die Verwaltung eines Bankaccounts; Control), BO für alle Objekte die im wesentlichen der Datenhaltung dienen; Model), DAL für alles das die Datenspeicherung betrifft (Sprich: Wie werden die Daten aus der Datenbank geholt und wie gespeichert...).

Model und View wäre z.B.:
MeinProjekt::AddressVerwaltung::BO::Person (Model)
MeinProjekt::AddressVerwaltung::UI::PersonAnzeige (View, Anzeige/Bearbeitung Einzeldatensatz)
MeinProjekt::AddressVerwaltung::UI::PersonListe (View, Anzeige Listenform)

Wobei bei der Benennung natürlich auch der persönliche geschmack (oder Unternehmensvorgaben) reinspielen...

cu André

asc schrieb:

Das Model sind die Daten, dies kann eine Klasse sein, dies können aber auch mehrere sein. Ich halte es für unsinnig für jedes Modell ein eigenen Namensraum zu schreiben.

Hmm... Aber wenn man sonst jede Funktion/... eh Person... nennen muss, damit man am Ende noch weiß, wo was ist, fand ich das eigtl gar ne so dumm...

asc schrieb:

"Die" View gibt es nicht, der Sinn vom MVC ist ja gerade das es mehrere Views geben kann, hier ist also die Benennung View für sich alleine genommen schlecht, soll jede View nochmal einen eigenen Namensraum bekommen?

Hmm.. Ich wollte nicht den Eindruck erwecken, dass es nur ein einziges View gibt... Aber in dem Beispiel hatte ich nur die Idee für ein einziges View... In dem Namespace (View) würde ich dann einfach auch noch die anderen Funktionen reinpacken - meinetwegen eine WriteSimple () Funktion oder so, die nur den Text ausgibt - und noch eine, die aller x Zeichen ne neue Zeile nimmt oder so was... Also so in etwa (nur vll mit besseren Namen ^^):

namespace Beispiel
{
 namespace View
 {
  void WriteTo (...);
  void WirteSimple (...);
  void WriteExtended (...);
 }
}

asc schrieb:

(Okay, bei mir wär die "View" eh in einen anderen Namensraum, da ich UI (UserInterface) von BL (BusinessLogic) etc. trenne).

Hmmm... Hört sich gar nicht mal so dumm an, das so rum zu machen ^^

Danke

Mit welchem Diagramm kann man MVC im UML modellieren?

Lg

drakon

So ziemlich alles anwesend, was es gibt:
http://www.jeckle.de/umltools.htm