Wo bring ich die datenbankanfragen unter?

[MontyBurns]

hi

ich arbeite mich gerade in swing ein und frag mich wie ich am geschicktesten die datenbankanfragen unterbringe
wollte keine Jframe-klasse schreiben in der das gui gebaut wird, und auch die datenbankabfragen drin stehen

dachte mir das man das ganze vlt im model der jeweiligen komonete unterbringen kann
hab aber leider noch niergendwo ne "richtlinie" gefunden wie man das am geschicktesten anstellt ....

vlt hat ja jmd nen tipp für mich

würd mich freun

MontyBurns

 

[outbreaker]

Hallo

Eigentlich werden in der OO Programmierung Klassen in Control Boundary und Control getrennt
Boundary ist deine GUI
Control ist deine Datenbank abfrage
Entity sind deine Datenhaltungsklassen

Du solltest dir also auf jedenfall eine eigene Klasse für das Abfragen der Datenbankinformationen anlegen und das nicht mit in die GUI hauen. Das würde das ganze auch sehr unübersichtlich machen

Robustheitsanalyse

 

[mimo]

Ich denke so pauschal lässt sich das nicht festlegen. das kommt darauf an wie komplex deine Abfragen sind. Und wie deine Views aufgebaut sind. Du kannst natürlich die Tabellen 1:1 aus der Datenbank Darstellen lassen, aber wie sieht es aus wenn deine Metadaten von den der Tabelle im View abweichen solln?

 

[MontyBurns]

hm...
was ich mich hald frage, ob ich jetzt eine klasse baue mit der eine relation ausgelesen wird un dann die einzelenen tupel in einer schleife in z.b. das defaultListModel einfüge, oder ob man vlt das DefaultListModel erweitert, und das ganze direkt darin implementiert

auf meiner suche nach einer antwort hab ich viele swing-tutorials gesehen, aber leider keins das mir zeigen konnte wie so eine anwendung gebaut/strukturiert wird, also wo welche funktionalität rein kommt ....

mich würd mal eine kleine swing anwendung sehen die man als vorbild nehmen kann wie sowas strukturiert wird

MontyBurns

 

[outbreaker]

Ich mache das so:


Control

Klasse fragt die Daten bei der Datenbank ab und schreibt Sie in ein ListModel (für die Abfrage übergibst du der Klasse z. B. dein aktuelles Model oder lässt dir eines zurück geben)

Entity

ListModel Klasse welche die Daten für deine Table enthält
-> wird von der Control Klasse befüllt

Boundary

GUI Klasse welche die Liste enthält
diese Klasse stößt das abrufen der Daten dann über die Control Klasse an


Hilft dir das weiter oder verstehe ich deine Frage falsch?

 

[MontyBurns]

ja
glaub das war ein ganz guter denkanstoss

aber gibt es keine texte die sich damit beschäftigen wie man sowas aufbaut?
sonst darf man sich nciht wundern das alle alles in eine klasse stecken ...

danke (freu mich noch über andere anregungen)

MontyBurns

 

[outbreaker]

Das ist nicht java spezifisch einfach mal allgemein nach Objektorientierte Programmierung gucken bzw auch UML
ich werde mal zu Hause in meine Studiumsunterlagen gucken ob ich da ein paar gute Hinweise bzw Literatur finde

Schreibe ich dir dann

 

[MontyBurns]

ich glaube ich kenn mich objektorientierung recht gut aus
hab aber bis jetzt nie swing sachen programmiert und weiss nicht was da die übliche vorgehensweise ist solche strukturprobleme zu lösen
ich glaub was mich verwirrt ist, das überall geschrieben wird man soll darstellung von der logik und der datenhaltung trennen, aber nirgens konkret gezeigt wird wie das normalerweise umgesetzt wird

 

[Gast2]

Such mal nach Design Pattern/Entwurfsmuster die zeigen dir wie du mit Strukruprobleme und noch mehr umgehen kannst...

 

[MontyBurns]

Design Pattern/Entwurfsmustet sind mir ein begriff
und ich hab das MVC-pattern glaub ich halbwegs verstanden
nur weiss ich nciht wie ich das am ende umsetzen soll

mir würde glaub ich schon ein grobes uml-diagramm nützen

MontyBurns

 

[Gast2]

public class GUI extends JFrame implements ActionListener{
	
	private JTextField txtID;
	public GUI()
	{
		super("Kleines Beispiel");
		setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
		setLayout(new GridLayout(1,2));
		getContentPane().add(new JLabel("ID"));
		txtID=new JTextField(20);
		txtID.addActionListener(this);
		getContentPane().add(txtID);
		
		pack();
		setVisible(true);
	}

	public void actionPerformed(ActionEvent arg0) {
		Cd cd =new Cd(txtID.getText());
		Datenbank.insertCd(cd):
		
	}
	
	public static void main(String[] args) {
		new GUI();
	}

}

public class Cd {

	private String id;
	
	public Cd(String id)
	{
		this.id=id;
	}

	public String getId() {
		return id;
	}

	public void setId(String id) {
		this.id = id;
	}
}

public class Datenbank....
...
...
...

so oder sowas ähnliches

www.libra.de/target/javaArticleMVC;jsessionid=73F42D04E6D23F58C2BFB1B1267CC9BD#pattern

 

[smjergol]

public class Cd {

	private String id;
	
	public Cd(String id)
	{
		this.id=id;
	}

	public String getId() {
		return id;
	}

	public void setId(String id) {
		this.id = id;
	}
}

public class Datenbank....
...
...
...

so oder sowas ähnliches

www.libra.de/target/javaArticleMVC;jsessionid=73F42D04E6D23F58C2BFB1B1267CC9BD#pattern[/quote]

Hm... Die CDs sind ja die Datenbank bzw. werden darin sicherlich gespeichert, daher würde ich die Methoden um die CD zu adden, löschen , auslesen etc... auch in dieser Datenbank Klasse unterbringen.

 

[byte]

Eigentlich werden in der OO Programmierung Klassen in Control Boundary und Control getrennt
Boundary ist deine GUI
Control ist deine Datenbank abfrage
Entity sind deine Datenhaltungsklassen

Boundary = GUI? Hab ich noch nie gehört. ???:L

Die klassische Vorgehensweise ist eigentlich Trennung von GUI und Logik durch MVC, wobei die DB-Anfragen als zusätzliche Schicht über DAOs passiert (Data Access Objects).

 

[outbreaker]

Eigentlich werden in der OO Programmierung Klassen in Control Boundary und Control getrennt
Boundary ist deine GUI
Control ist deine Datenbank abfrage
Entity sind deine Datenhaltungsklassen

Boundary = GUI? Hab ich noch nie gehört. ???:L

Die klassische Vorgehensweise ist eigentlich Trennung von GUI und Logik durch MVC, wobei die DB-Anfragen als zusätzliche Schicht über DAOs passiert (Data Access Objects).

So habe nochmal nachgelesen ob ich mich irre aber habe das gefunden:

...Boundary ist englisch und steht für Grenze. Boundary-Klassen grenzen die Software von der Umgebung ab. Boundary-Klassen sind das Interface der Software.

Kein Akteur (siehe Tutorial1 "Use-Case-Diagramme") kann mit einem System kommunizieren, ohne eine Boundary-Klasse zu nutzen.

Jeder Weg in oder aus der Software muss über eine Boundary-Klasse führen. Alle Formulare und GUI Elemente sind Boundary-Klassen. Ebenso wie Schnittstellen zu Datenbanken, Importschnittstellen oder Schnittstellen zu anderer Software. ...

Quelle


oder

• Boundary-Klassen stehen an der Grenze des betrachteten Software-
Systems. Sie bedienen den Benutzer oder nehmen von ihm Aufträge
entgegen. In Web-Applikationen liefern die Boundary-Klassen beispielsweise
eine Webseite oder ein Eingabeformular aus. Sie nehmen auch Eingaben des
Benutzers entgegen, bereiten sie auf und leiten sie an die Control-Objekte
weiter.
• Auf Konzept-Ebene (Analyse) sollen Boundary-Klassen vorallem aufzeigen,
was man dem Benutzer auf dem GUI (beispielsweise im Browser)
präsentieren will.

Quelle Seite 85


und bei wikipedia stehts auch so

...

 

[outbreaker]

laut dem einen was ich gefunden habe gehören deine Datenbankabfragen dann wohl doch eher zu Boundary als zu Control
hätte vom Gefühl her gedacht, dass es eher Control ist

EDIT

und MVB ist doch eigentlich genau das selbe oder sehe ich das falsch

Model = Entity
Control = Control
View = Boundary

oder ???:L

 

[byte]

Deine Links beziehen sich alle auf UML und Use Cases. Scheint also eher ein akademisches Thema zu sein.

Ich bilde mir ein, einen Großteil der Entwurfsmuster zu kennen. Dort suchst Du diese Begriffe vergeblich. Und Pattern liegen nun mal näher an der Realität der Softwareentwicklung als visuelle Modellierung.

Ich empfehle Dir mal, die Bibel zu lesen.

 

[outbreaker]

Ja die beziehen sich auf UML davon bin ich ja bei meiner Aussage auch ausgegangen :wink:
und die Kernaussage von Trennung "Control / Daten / Anzeige" ist wohl von uns beiden gleich

Mir wurde das halt mit den Begriffen Boundary Control Entity gelehrt aber das kann man sicher auch Model / View / Control nennen der Kern bleibt der selbe

Wir hatten im Studium unter anderem mit diesem Buch gearbeitet

 

[maki]

MVC ist kein Pattern, sondern "nur" ein Konzept, bzw. eine "high level architecture".

Links zu Seiten die MVC für Webanwednungen beschreiben sind bei Fragen zu Swing/AWT ziemlich nutzlos, da sich die Konzepte und vor allem die Implementierungen sehr unterscheiden.

Ansonsten wäre es gut wenn man zumindest ähnliche Beriffe verwendet, da man sich sonst gegenseitig nicht vesteht, "boundary" halte ich persönlich für weniger gut, da zu allgemein.

 

[outbreaker]

boundary ist allgemeiner als View das sehe ich ein
aber ich glaube das was es zu verstehen gab wurde von MontyBurns verstanden meiner Meinung nach
Also das er es nicht alles in eine Klasse hauen sollte :wink:

 

[maki]

Also das er es nicht alles in eine Klasse hauen sollte icon_wink.gif[/quote9
Ja, und darauf kommt es an.

 

[byte]

Mir wurde das halt mit den Begriffen Boundary Control Entity gelehrt aber das kann man sicher auch Model / View / Control nennen der Kern bleibt der selbe

Man sollte halt eine Sprache sprechen, damit andere verstehen was man meint. Mit Boundary kann imo in der Softwareentwicklung niemand was anfangen, MVC kennt hingegen jeder.
Nicht immer entspricht das, was man im Studium lernt, auch der angewandten Praxis. Sehr viel ist akademisch oder fernab dessen, was zur Best Practice in der Industrie zählt. Das liegt daran, dass viele Mitarbeiter an der Uni nie oder nur sehr kurz in der Industrie entwickelt haben.

 

[Gast2]

Hm... Die CDs sind ja die Datenbank bzw. werden darin sicherlich gespeichert, daher würde ich die Methoden um die CD zu adden, löschen , auslesen etc... auch in dieser Datenbank Klasse unterbringen.

nichts anderes hab ich gemacht

 

[outbreaker]

Mir wurde das halt mit den Begriffen Boundary Control Entity gelehrt aber das kann man sicher auch Model / View / Control nennen der Kern bleibt der selbe

Man sollte halt eine Sprache sprechen, damit andere verstehen was man meint. Mit Boundary kann imo in der Softwareentwicklung niemand was anfangen, MVC kennt hingegen jeder.
Nicht immer entspricht das, was man im Studium lernt, auch der angewandten Praxis. Sehr viel ist akademisch oder fernab dessen, was zur Best Practice in der Industrie zählt. Das liegt daran, dass viele Mitarbeiter an der Uni nie oder nur sehr kurz in der Industrie entwickelt haben.

Mit ein und der selben Sprach sprechen bin ich ganz deiner Meinung.
Aber das mit Bondary und Co keiner was anfangen kann würde ich mal bezweifeln aber gut.
Wir hatten einen externen Dozenten und bei ihm wird das auch so praktiziert in der Firma. :wink:
aber OK das kann schon sein das der Großteil mehr mit MVC anfangen