Dies ist eine statische Kopie unseres alten Forums. Es sind keine Interaktionen möglich.
This is a static copy of our old forum. Interactions are not possible.

chefstatist

Trainee

  • "chefstatist" is male
  • "chefstatist" started this thread

Posts: 57

Date of registration: Jan 9th 2002

Location: Hannover-Nordstadt

1

Wednesday, June 4th 2003, 2:24pm

Anwendungsarchitektur

Ich bin zur Zeit dabei, eine Anwendung mit einem eher prozeduralen Design neu zu schreiben. Bei dieser Gelegenheit soll diese mit einer neuen Programmiersprache (C# statt Visual Basic) und -natürlich- mit einem neuen Ansatz, also objektorientiert, geschrieben werden.

Die alte Anwendung lag ziemlich direkt auf der Datenbank, im Code sind überall SQL-Anweisungen verstreut. Der Nachteil dieser Lösung ist ziemlich offenkundig: Änderungen im Datenmodell sind nicht möglich und ein Wechsel der Datenbank schwer (zur Zeit Access, für die Zukunft Access sowie MS-SQL-Server).

Die neue Anwendung soll also verschiedene Klassen besitzen, da sie aus dem Projektmanagement Bereich kommt zum Beispiel folgende:
* Projekt-Klasse
* Ressourcen-Klasse
* Aufgaben-Klasse

Was mich nun beschäftigt ist, welches Design ich zum Suchen von Datensätzen benutzen sollte.

Mir schwebt ungefähr folgendes vor: Ich habe statische Klassen, die als Suchklassen fungieren. Eine könnte zum Beispiel ProjektSuch-Klasse heissen.
Sie hätte dann vielleicht eine Methode wie:

Source code

 
1

IEnumerator alleProjekte ( void )
-- würde einen Iterator über alle Projekte zurückgeben

oder:

Source code

 
1

IEnumerator suchNachName ( String Pattern )
-- würde zum Beispiel nach "PROJ_%_2003_%" oder ähnlichem Suchen

Der Nachteil ist, das mit diesen Klassen nicht besonders flexibel gesucht werden könnte - für eine neue Such-Art müsste man der Klasse eine neue Methode geben.

Hat einer von Euch so etwas in der Art schon einmal implementiert oder vielleicht auch einfach so eine bessere Idee?
  • Send private message

paradroid

Junior Schreiberling

Posts: 231

Date of registration: Feb 28th 2002

2

Wednesday, June 4th 2003, 3:38pm

Wie wäre eine mehrstufige Suchhierarchie:

An der Basis eine Klasse "Sucher", die nur eine (oder ein paar) generische Methode

IEnumerator search( String sqlQuery )

hat. Damit lässt sich -- mit SQL-Kenntnissen -- schonmal jede Anfrage realisieren.
Davon abgeleitet könnten nun mehrere spezialisierte Klassen existieren: ProjektSucher etc.

Das ganze wäre natürlich um so sinnvoller, wenn man der Basisklasse noch ein paar Methoden zufügen könnte, die auch allgemeiner später genutzt werden können, z.B. wiederhole letzte Anfrage und sortiere diesmal alphabetisch u.ä.

# transmission terminated #
  • Send private message

PhilRM

Gründer

  • "PhilRM" is male

Posts: 867

Date of registration: Dec 9th 2001

Location: Hannover

Occupation: äh... :)

3

Wednesday, June 4th 2003, 3:45pm

Schau dir mal das DAO-Pattern an. Ist zwar Java, aber weit davon weg ist c# ja nicht.

http://java.sun.com/blueprints/corej2eep…cessObject.html
"Sie haben also einen, äh, einen Master of Bachelor?" (Human Resources, T-Systems, Cebit)
  • Send private message

chefstatist

Trainee

  • "chefstatist" is male
  • "chefstatist" started this thread

Posts: 57

Date of registration: Jan 9th 2002

Location: Hannover-Nordstadt

4

Wednesday, June 4th 2003, 3:50pm

(bezieht sich auf Paradroid)

ja, das klingt von der Idee her schon mal nicht schlecht.

Ich hab mir vorgestellt, das es vielleicht etwas mehr in Richtung OO gehen könnte, ich wollte so wenig SQL-Code wie möglich auf der Client-Seite drin haben.

Das Problem ist nämlich, das Access manche Sachen der SQL-Spez. etwas merkwürdig auslegt (vorallem Abfragen nach Datumswerten, da erfordert es einen # als Trenner und nicht das normale ').

Ich hatte mir das eher so vorgestellt:
(Methoden von Suchklasse)
.setDatumsBereichBeginn ( 24.03.2001 );
.setDatumsBereichEnde ( null );
.setName ( "%lalala%" );
Iterator it = .getIterator();

Dann könnte man innherhalb der Suchklasse die Sonderbehandlung für den Datumscode kapseln und hätte auf der Clientseite sauberen Code ohne dauern abfragen zu müssen, auf welcher Datenbank man arbeitet.

Oder gibt es alternativ vielleicht einen frei verfügbaren SQL-Parser, den man in die Klasse einbinden könnte? Dann könnte man sich auf Client-Seite auf einen SQL-Dialekt verlassen und die Such-Klasse könnte dann Datenbankspezifisches SQL daraus basteln.
  • Send private message

chefstatist

Trainee

  • "chefstatist" is male
  • "chefstatist" started this thread

Posts: 57

Date of registration: Jan 9th 2002

Location: Hannover-Nordstadt

5

Wednesday, June 4th 2003, 3:59pm

(bezieht sich auf PhilRM)

das sieht sehr interessant aus. Gibt es davon mittlerweile auch schon eine freie Implementierung? Als ich dazu das letzte Mal einen Artikel in iX gelesen habe, war noch alles kommerziell und (glaub ich) ziemlich teuer.

Allerdings wird mir nicht ganz klar, wie die Suche dort gelöst ist. Scheinbar gibt Sun dafür nichts vor und überlässt es dem Entwickler, sich dafür eine geeignete Methode auszudenken.

Kennst Du sowas ähnliches vielleicht auch für C#?
  • Send private message

PhilRM

Gründer

  • "PhilRM" is male

Posts: 867

Date of registration: Dec 9th 2001

Location: Hannover

Occupation: äh... :)

6

Wednesday, June 4th 2003, 6:27pm

Quoted

Original von chefstatist
Gibt es davon mittlerweile auch schon eine freie Implementierung?


Implementierungen kenne ich gar keine, ich meinte auch mehr das Pattern an sich, also einen Vorschlag für eine mögliche Modellierung ... das ist ja dann für alle Sprachen geeignet. :)
"Sie haben also einen, äh, einen Master of Bachelor?" (Human Resources, T-Systems, Cebit)
  • Send private message

paradroid

Junior Schreiberling

Posts: 231

Date of registration: Feb 28th 2002

7

Thursday, June 5th 2003, 8:25am

Quoted

Original von chefstatist
(bezieht sich auf Paradroid)
[...]
Ich hab mir vorgestellt, das es vielleicht etwas mehr in Richtung OO gehen könnte, ich wollte so wenig SQL-Code wie möglich auf der Client-Seite drin haben.
[...]
Ich hatte mir das eher so vorgestellt:
(Methoden von Suchklasse)
.setDatumsBereichBeginn ( 24.03.2001 );
.setDatumsBereichEnde ( null );
.setName ( "%lalala%" );
Iterator it = .getIterator();

Das meinte ich damit, dass man in die Basisklasse noch mehr Funktionalität einbauen muss. Leider kenne ich nur ein wenig Oracle & MySQL, weiß also nicht, was man da braucht, aber ich denke mal, die Inkompatiblität sollte nicht so riesig sein.
Die generische search-Methode sollte eigentlich auch nur eine Hintertür sein, um jederzeit jede Erweiterung zu realisieren, könnte man ja protected machen...

Quoted


Oder gibt es alternativ vielleicht einen frei verfügbaren SQL-Parser, den man in die Klasse einbinden könnte? Dann könnte man sich auf Client-Seite auf einen SQL-Dialekt verlassen und die Such-Klasse könnte dann Datenbankspezifisches SQL daraus basteln.

Unwahrscheinlich, ist mir leider nichts bekannt. Zumindest über freshmeat habe ich nichts finden können, aber es gibt ja noch google. Viel Glück auf jeden Fall!

# transmission terminated #
  • Send private message

chefstatist

Trainee

  • "chefstatist" is male
  • "chefstatist" started this thread

Posts: 57

Date of registration: Jan 9th 2002

Location: Hannover-Nordstadt

8

Thursday, June 5th 2003, 4:13pm

vielen Dank für Eure Ideen!

Ich werde mich nochmal in diesem Thread melden und berichten, wie ich es dann umgesetzt habe, falls es Euch interessiert.

Fabian
  • Send private message