Wie viel Geschäftslogik gehört zur RIA-Services-Schicht?

8

Ich habe kürzlich mit Silverlight, RIA Services und Entity Framework mit .NET 4.0 experimentiert. Ich versuche herauszufinden, ob dieser Stapel für die Verwendung in einem meiner kommenden Projekte sinnvoll ist. Es scheint, als könnten diese Technologien sehr produktiv für die Entwicklung von Anwendungen sein, aber ich habe Mühe zu entscheiden, wie eine Anwendung auf diesem Stack aufgebaut werden sollte.

Das Hauptproblem, das ich habe, ist, dass in den meisten Demos, die ich gesehen habe, die meisten Geschäftslogik als DataAnnotations und benutzerdefinierte Validierungen in der RIA-Services-Domain-Service-Klasse endet. Das erscheint mir unpassend. Ich betrachte den Domain-Service als einen verklärten Web-Service, der es einfach macht, Informationen an den Client zu senden. Aber das meiste, was ich gesehen habe, scheint den Domain-Service als Hauptquelle der Geschäftslogik in der Anwendung zu orientieren.

Also, meine Fragen:

  • Was ist der beste Ort für Geschäftslogik (Regeln, Validierungen, Verhaltensweisen, Autorisierung) in einer Anwendung, die diesen Stack verwendet?
  • Gibt es Richtlinien zur Verwendung dieses Stacks auf Architekturebene?

Meine Fragen beziehen sich auf große, komplexe und langlebige Anwendungen. Offensichtlich ist dies für eine Anwendung von nur wenigen Bildschirmen weniger von Bedeutung.

Bearbeiten: Eine andere Sache, die ich erwähnen wollte, ist, dass Sie die Domain-Service-Klasse offensichtlich blöd machen können, aber dann verlieren Sie eine Menge der automagischen Entity-Informationen (z.B. Validierungen), die an den Client gesendet werden. Und wenn Sie dann verlieren, ist es sinnvoll, RIA-Dienste zu nutzen?

    
RationalGeek 24.05.2010, 14:00
quelle

2 Antworten

1

Unser Team implementiert gerade eine Silverlight-App auf dem RIA-Stack. Wir haben beschlossen, ein Domänenmodell auf den RIA-Entitäten zu erstellen. Darüber hinaus haben wir uns entschieden, dem MVVM-Muster zu folgen, um UI-Interaktionen zu modellieren.

Bisher habe ich die folgenden Vorteile festgestellt:

  1. Domain-Klassen sind ein schöner Ort, um Business-Logik einschließlich komplexer Validierungen zu platzieren.
  2. Domänenklassen verwenden die RIA-Entitäten und den Kontext als Schnittstelle zum Datenspeicher.
  3. Domain-Klassen werden nach Geschäftsanforderungen modelliert und erfordern keine Eins-zu-Eins-Beziehung mit RIA-Entitäten.
  4. Einfache UI-Validierungen können in den ViewModels enthalten sein.

Eine weitere Sache, die es zu beachten gilt, ist, dass wir unsere eigene Identity Map für die Parallelität implementiert haben und die schmutzige Verfolgung in den RIA-Kontext verschoben haben.

In der Praxis erfordert diese Architektur ein wenig mehr Programmieraufwand, zahlt sich aber mit Lesbarkeit und Wartungsfreundlichkeit aus. Selbst für einfache CRUD-Anwendungen würde ich diese Praxis befolgen. Die Fähigkeit, ein Domänenmodell zu erstellen, das den Problembereich genauer darstellt, ist ein überzeugender Vorteil.

    
randolphcabral 26.05.2010, 01:42
quelle
0

Im Allgemeinen ist es produktiver, mit der Technologie zu arbeiten als dagegen.

Wenn Sie sagen, dass die Geschäftslogik in DataAnnotations und benutzerdefinierten Validierungen endet, ist dies möglicherweise der "beste" Platz für die Entwicklerproduktivität in der ersten Version des Systems.

Ich habe das Gefühl, dass diese Technologie ihre Stärken beim schnellen Erstellen von Crud-Anwendungen hat. Wenn Sie komplizierte Geschäftslogik haben, können Sie zwischen der Silverlight-Anwendung und den RIA-Diensten eine zusätzliche Business-Schicht finden.

Ich habe noch nicht versucht, etwas wirklich Neues daraus zu machen, wir werden die Antwort darauf erst wirklich kennen, nachdem wir es einige Zeit benutzt haben.

    
Shiraz Bhaiji 25.05.2010 20:06
quelle