Architektur einer modularen Webanwendung

Ideen? Anregungen?

DocJunioR

Es gibt da die Schichten-Architekturen.

[Oberfläche]
[Geschäftslogik]
[Datenbasis]

Die Datenbasisschicht bildet eine Abstraktion der Datenbank, also Zugriffsfunktionen, login, etc.
Die Geschäftslogik bildet die eigentliche Bearbeitung der Daten
Die Oberfläche dient nur(!) der Anzeige, Eingabe und ggf. vorprüfung von Daten.

Die Verbindung zwischen Oberfläche und Geschäftslogik ist im Optimalfall so weit getrennt, dass man die Oberfläche ohne großen Aufwand austauschen kann.
Interessant ist das Design Pattern "Model View Controller"

Geschäftslogik- und Datenbankschicht sind gelegentlich auch ziemlich mit einander verwurstelt und gehen dann in einer Schicht auf. Nicht unbedingt designtechnisches Optimum, aber manchmal wärs sonst nen ziemlicher overhead

DocJunioR schrieb:

Es gibt da die Schichten-Architekturen.

[Oberfläche]
[Geschäftslogik]
[Datenbasis]

Die Datenbasisschicht bildet eine Abstraktion der Datenbank, also Zugriffsfunktionen, login, etc.
Die Geschäftslogik bildet die eigentliche Bearbeitung der Daten
Die Oberfläche dient nur(!) der Anzeige, Eingabe und ggf. vorprüfung von Daten.

Die Verbindung zwischen Oberfläche und Geschäftslogik ist im Optimalfall so weit getrennt, dass man die Oberfläche ohne großen Aufwand austauschen kann.
Interessant ist das Design Pattern "Model View Controller"

Geschäftslogik- und Datenbankschicht sind gelegentlich auch ziemlich mit einander verwurstelt und gehen dann in einer Schicht auf. Nicht unbedingt designtechnisches Optimum, aber manchmal wärs sonst nen ziemlicher overhead

Das geht schief, schau mal auf thedailywtf.com es gibt keinen business layer und alle Anwendungen die versuchen die business logic in einen eigenen layer zu bekommen wandern regelmäßig dort auf die Titelseite.

Ansonsten nehmt RubyOnRails, das gibt euch ein schönes Design vor, die Sprache und Programmierung ist nicht zu schwer, hört sich doch optimal an, oder nicht?

Shade Of Mine

Haha schrieb:

Ansonsten nehmt RubyOnRails, das gibt euch ein schönes Design vor, die Sprache und Programmierung ist nicht zu schwer, hört sich doch optimal an, oder nicht?

Ist Rails immer noch die Plattform der Zukunft?
Dachte diese seifenblase sei schon geplatzt...

PRIEST

Shade Of Mine schrieb:

Haha schrieb:

Ansonsten nehmt RubyOnRails, das gibt euch ein schönes Design vor, die Sprache und Programmierung ist nicht zu schwer, hört sich doch optimal an, oder nicht?

Ist Rails immer noch die Plattform der Zukunft?
Dachte diese seifenblase sei schon geplatzt...

is sie eig. auch ^^

DocJunioR

Haha schrieb:

DocJunioR schrieb:

Es gibt da die Schichten-Architekturen.

[Oberfläche]
[Geschäftslogik]
[Datenbasis]

Die Datenbasisschicht bildet eine Abstraktion der Datenbank, also Zugriffsfunktionen, login, etc.
Die Geschäftslogik bildet die eigentliche Bearbeitung der Daten
Die Oberfläche dient nur(!) der Anzeige, Eingabe und ggf. vorprüfung von Daten.

Die Verbindung zwischen Oberfläche und Geschäftslogik ist im Optimalfall so weit getrennt, dass man die Oberfläche ohne großen Aufwand austauschen kann.
Interessant ist das Design Pattern "Model View Controller"

Geschäftslogik- und Datenbankschicht sind gelegentlich auch ziemlich mit einander verwurstelt und gehen dann in einer Schicht auf. Nicht unbedingt designtechnisches Optimum, aber manchmal wärs sonst nen ziemlicher overhead

Das geht schief, schau mal auf thedailywtf.com es gibt keinen business layer und alle Anwendungen die versuchen die business logic in einen eigenen layer zu bekommen wandern regelmäßig dort auf die Titelseite.

Ansonsten nehmt RubyOnRails, das gibt euch ein schönes Design vor, die Sprache und Programmierung ist nicht zu schwer, hört sich doch optimal an, oder nicht?

Aalso ich sag mal so, die Frage war nach der Architektur. Man sollte die logische Architektur grundsätzlich von der physischen Umsetzung abstrahieren

danke für die infos bislang.
das mit dem 3-tier dingens dacht ich mir schon so.
rails macht das mvc ja auch konsequent.
die kernanwendung soll die daten bloss holen, jobs verteilen und darstellen. dafür ist ruby wohl am ehesten geeignet, aufgrund der entwicklungsgeschwindigkeit.

meine frage ist nun weiter, wie ich am schlausten die module anspreche. aber es soll halt gut erweiterbar sein. die module selbst werden ev. in java sein, da sie zt sehr rechenintensiv ausfallen könnten. die module müssen auch nicht zwingend auf der gleichen maschine laufen. daher dachte ich an webservices. aber bin da unsicher ob REST oder SOAP besser geeignet ist, oder was ganz anderes.

hm verwirrend?

also mal ganz simpel:
user gibt daten ein.
controller guggt in der db ob resultate da sind
wenn ja, gib sie als view zurück.
wenn nein, schick die daten an die services und lass sie rechnen.
warte...
resultate da, gib sie als view zurück.

oder so ähnlich

*püshchen*

Was du brauchst: Client => Service architektur.

Wenn du eh auf der Suche nach einer serviceorientierten Architektur bist, solltest du dir mal den Ansatz von serviceorientierten Benutzeroberflächen anschauen.

Der Ansatz dahinter ist nicht neu (genau so wie AJAX und das Web2.0). Dennoch sehr effizient.

Das Prinzip ist folgendes (Client):
* Schreibe deine Webseite in JavaScript (möglichst komplett). MVC=>MVP Ansätze haben sich zu recht durchgesetzt. Geschäftslogik und Design sollte man trennen. Daher empfehle ich dir hier das Framework EJS (http://embeddedjs.com/)!
* Für die Kommunikation mit deinen Services (der Abstraktionsmöglichkeiten halber würde ich SOAP mit AXIS2 etc. nutzen) kannst du sehr gut JQuery (http://jquery.com/) nutzen. Dort gibt es Transformatoren mit denen du vom XML sofort zu JSON umwandeln kannst. Es gibt hier auch einige SOAP Plugins mit denen du Webservices ansprechen kannst. JSON direkt anzubieten ist leichtgewichtiger, aber nicht so kompatibel zu anderen (besonders älteren) programmiersprachen. Services solltest du über RESTful strukturierte URLs verfügbar machen.
* Das Design wie es sich gehört nicht mit Tabellen und komplett in CSS.

Jetzt ist es absolut egal, welche Logik hinter dem Service steckt. Es könnten 2 weitere Schichten aber auch 5 oder mehr Schichten mit SAP-Systemen und batching etc. sein. Der Service rettet dich hier vor der Komplexität die im Backend steckt. Auch andere Applikationen können die Services weiterhin nutzen. So kannst du Service chaining etc. betreiben. Falls du auf JavaScript verzichten möchtest, kannst du eine Applikation als Konsumenten der Services schreiben die HTML ausgibt

Das Prinzip ist folgendes (Server):
- Mit irgendeiner Bibliothek wie AXIS2, Xfire etc. bietest du SOAP services an.
- Dahinter ist es egal was passiert

Praktikabel: Das Backend mit Grails/Rails etc. schreiben. So kannst du zumindest die CRUD Aktionen in minuten implementieren. Und sparst jede Menge Code (high level abstraktion / Ausdrucksstärke).

Beispiel für AJAX Abfrage mit JQuery:

$.ajax({
  url: "test.html",
  cache: false,
  success: function(html){
    $("#results").append(html);
  }
});

Insgesamt wichtig: Eine Service Registry schreiben die alle Teammitglieder wissen lässt welche Services es gibt und was sie tun.

hoi

sehr cool, danke dir. super!