Die ideale Architektur für Businessapplikationen?

Naja, das NotifyPropertyChanged währe ja eher Client-Seite.
Serverseite müsste verglichen werden ob sich ein Property geändert hat.

An welcher stelle würdet ihr die Prüfung ob sich ein objekt veränder hat halten?

Das lässt sich nicht pauschal beantworten. Denke nur mal eine Rückgängig-Funktion a la Word. Wenn der Client nicht weiss, welche Objekte geändert, gelöscht oder zugefügt wurden und welche Werte die Eigenschaften der geänderten Objekte ursprünglich hatten, muss er einen erneuten Server-Roundtrip anstossen, um den aktuellen Zustand der DB neu abzurufen. Bei steigender Benutzer- und Transaktionsanzahl werden diese Roundtrips teuer. Deshalb kann es durchaus angebracht sein, Veränderungen an Objekten bereits im Client zu überwachen. Der Server muss zu persistierende Objekte trotzdem nochmals gegen die DB prüfen, da der Server sich auch um das Persistieren der Änderungen kümmert.

Es gibt eine sehr gute und ressourcensparende Alternative, welche die Frage komplett überflüssig macht. Wenn das Objekt selbst weiss, ob es verändert bzw. gelöscht oder neu angelegt wurde, ist weder im Client noch im Server eine Prüfung erforderlich. Das Objekt selbst stellt sicher, dass Änderungen protokolliert und ggf. die ursprünglichen Werte zwischengespeichert werden. Das ganze gibt es seit .NET 1.0 frei Haus und nennt sich DataSet bzw. DataTable. Die typsichere Variante wird als Typed DataSet bzw. Typed DataTable bezeichnet. Die als Beispiel angesprochene Rückgängig-Funktion ohne Server-Roundtrip ist bereits eingebaut:

// Änderungen verwerfen und ursprünglichen Zustand wiederherstellen
myDataSet.RejectChanges();

Auch die Prüfung auf dem Server entfällt. Anhand der RowState-Eigenschaft jeder einzelnen DataRow in einer DataTable weiss der Server sofort ob eine Zeile erstellt, geändert oder gelöscht wurde und kann sofort die passenden INSERT, UPDATE und DELETE-Statements an die DB absetzen. Das ist in jedem Fall wesentlich performanter, als wenn zuvor erst noch ermittelt werden muss, welche Zeilen überhaupt erstellt oder geändert wurden. Gelöschte Zeilen können bei herkömmlichen Objektlsiten (z.B. List<Customer>) sogar überhaupt nicht erkannt werden, da sie in der Liste einfach nicht mehr vorhanden sind.

Typisierte DataSets sollten allerdings nicht eingesetzt werden, wenn auch Nicht-.NET-Clients (z.B. in Java geschrieben) unterstützt werden sollen/müssen. Bei einer reinen .NET Applikation sind sie aber ideal.

Hallo,
nochmal zu der Event-Sache.
Ist der Policy Injection Application Block der Enterprise Library nicht genau so etwas?

Hallo daniel,

ja, mit diesem Application Block kann man sowas umsetzen.

Hallo zusammen,

mal ne performance Frage:

Angenommen ich habe einen sehr leistungstarken DB-Server und eher heterogene Clienten. Ich habe meinen Datenzugriff sauber in einer Datenzugriffsschicht gekapselt und der Geschäftslogikschicht stehen alle benötigten BusinessObjekte zur Verfügung. Wie ich das jetzt rausgelesen habe, findet für üblich in einer "idealen Businessapplikation" die Rechenarbeit in der Geschäftslogikschicht statt. Nur wo wird diese Schicht ausgeführt? Wer leistet jetzt die Rechenarbeit? Der Client? Würde für mich erstmal bedenklich klingen, wenn man überlegt, dass auch in einer Businessanwendung sehr komplexe Berechnungen stattfinden können (Berechnung für Workflowabhängigkeiten, Plandatenberechnung, Kapazitätsberechnung, etc..). Oder ist das unbedenklich?

Da gibt es zig Möglichkeiten. Rich oder Fat Clients könnten die Berechnungen selbst durchführen, Thin Clients würden wohl eher die Arbeit der DB und den Zugriff selbiger oder einem Applikationsserver überlassen.

In einem heterogenen Umfeld setzt man wohl heutzutage auf Webanwendungen mit einem Browser als Rahmenapplikation oder Java, wenn man etwas mehr Ergonomie / Performance / Features im Client braucht. Wobei die eigentlichen Berechnungen hier wohl von den Servern getragen werden.

Die Frage ist, ob die Geschäftslogik mehr Richtung OLTP oder OLAP geht.

Hallo,
wie handhabst du die Authentifizierung, wenn ein Service einen anderen aufruft?
Speziell bei Events?
Einen eigenes Benutzerkonto für solche "internen" Service aufrufe oder mit den creditentials des ursprünglichen aufrufers?

wie handhabst du die Authentifizierung, wenn ein Service einen anderen aufruft?
Speziell bei Events?

Ich würde sagen, dass man das nicht pauschal sagen kann. Möglich ist beides. Ausgehend von einem Trusted-Server-Sicherheitsmodell ist es in den meisten Fällen einfacher, alles unter dem Dienstkonto des Servers auszuführen. Das schließt nicht aus, dass die Identität des ursprünglichen Aufrufers trotzdem mit übertragen wird und für Sicherheitsprüfungen zur Verfügung steht.

Events machen da keine Ausnahme. Für die Infrastruktur werden immer nur Nachrichten ausgetauscht. Das ist bei Remoting, ASP.NET Webdiensten und WCF übrigens gleichermaßen der Fall.