nicht angemeldet
Hi,
nur ein paar Anmerkungen (zu mehr traue ich mich nicht):
Hm, das verstehe ich nicht ganz. Warum ist eine Trennung unmöglich?
Eine Trennung koennte zum Beispiel mit irgendwelchen ".NET-Objekten" ins Auge gefasst werden: Objekte fuer die Geschaeftslogik, SPs fuer den "primitiven" Datenzugriff (CRUDL). Wenn die Geschaeftslogikobjekte aber das Schema nicht wirklich kennen (sollen), dann duerfen diese nicht JOINen. Konsequenz: sehr viel Traffic.
[VIEWS]
Diese habe ich fuer "meine" Zwecke noch nicht ernsthaft ins Auge gefasst. (Muss mal meditieren, was das bringen kann)
Ich bin auch der Meinung, dass die Business Rule vom Programm definiert werden soll,
denn Daten haben mit der Verarbeitung nichts zu tun; das sind zwei Einheiten.
Ich nicht. M.E. ist das Programm idealerweise nur eine Praesentationsschicht, die Benutzeranforderungen an die Business-Objekte, die wiederum an die Datenzugriffsobjekte weiterleitet. Geschaeftslogik laeuft am besten serverseitig.
Ich denke
jedoch, dass es bei wirklich sensitiven Applikationen (wie z.B. Bank) durchaus sinnvoll
sein kann, wenn das selbe zweimal umgesetzt ist (diese Redundanz erhöht die Sicherheit
und Stabilität des Gesamtsystems).
Glaube ich auch nicht. btw - Ich kenne nicht so viele sinnvollen Redundanzen. - Da faellt mir datenseitig eigentlich "auf die Schnelle" nur OLAP oder auch Redundanzen wegen Site-Autonomie oder auch Redundanzen wegen (teilweise abstruser) Performanceueberlegungen ein. "Logikseitig" muss ich "auf die Schnelle" ganz passen.
Gruss,
Lude