Projektstruktur für verteilte Anwendung

07/03/2008 - 14:21 von Michael Ertelt | Report spam
Hallo

es geht mir um einige Fragen zum Aufbau/Umstellung eines Projektes.
Es soll ein WCF Service entstehen, welcher eine ganze Reihe von Funktionen
anbietet.
Dazu müssen natürlich eine ganze Reihe von Contracts, Geschàftsregeln,
Ressourcenzugriffe geschrieben werden. Es handelt sich um etwa 100
DataContracts.

Eine Meinung ist, jeden Contract und weitere (wie genannt) in ein Assembly
zu verpacken um flexibel zu sein, als den Host per Konfiguration die
gewünschten Services anbieten zu lassen. Zusàtzlich soll so besser getestet
werden können. Dazu soll es eine ganze Reihe von Projektmappen geben, welche
jeweils nur die tatsàchlich benötigten Assemblies enthalten.

Mit dieser Meinung gehe ich aber nicht mit und möchte gerne Eure Meinung
dazu kennenlernen.

Ich denke...
... die Anzahl der Assemblies (etwa 100) x die 3 Schichten (Resource, Logic,
Contract) wirkt sich negativ auf die Übersichtlichkeit und zudem auf die
Performance zur Laufzeit aus
... da für jeden ServiceContract ein Binding benötigt wird, ist die Anzahl
der zu konfigurierenden Endpunkte zu groß (könnte man jedoch per Quellcode
erzeugen)
... ich halte es für besser verschiedene Contracts in Assemblies zu
gruppieren oder gar nur einen einzigen ServiceContract zu definieren.

Gibt es Quelle für Best Practices für den Aufbau einer derartigen
Architektur? Bisher habe ich nichts brauchbares gefunden.

Viele Grüße
Michael
 

Lesen sie die antworten

#1 0xB055
08/03/2008 - 10:25 | Warnen spam
Michael Ertelt wrote:
Hallo

es geht mir um einige Fragen zum Aufbau/Umstellung eines Projektes.
Es soll ein WCF Service entstehen, welcher eine ganze Reihe von
Funktionen anbietet.
Dazu müssen natürlich eine ganze Reihe von Contracts, Geschàftsregeln,
Ressourcenzugriffe geschrieben werden. Es handelt sich um etwa 100
DataContracts.

Eine Meinung ist, jeden Contract und weitere (wie genannt) in ein
Assembly zu verpacken um flexibel zu sein, als den Host per
Konfiguration die gewünschten Services anbieten zu lassen. Zusàtzlich
soll so besser getestet werden können. Dazu soll es eine ganze Reihe von
Projektmappen geben, welche jeweils nur die tatsàchlich benötigten
Assemblies enthalten.

Mit dieser Meinung gehe ich aber nicht mit und möchte gerne Eure Meinung
dazu kennenlernen.

Ich denke...
... die Anzahl der Assemblies (etwa 100) x die 3 Schichten (Resource,
Logic, Contract) wirkt sich negativ auf die Übersichtlichkeit und zudem
auf die Performance zur Laufzeit aus
... da für jeden ServiceContract ein Binding benötigt wird, ist die
Anzahl der zu konfigurierenden Endpunkte zu groß (könnte man jedoch per
Quellcode erzeugen)
... ich halte es für besser verschiedene Contracts in Assemblies zu
gruppieren oder gar nur einen einzigen ServiceContract zu definieren.

Gibt es Quelle für Best Practices für den Aufbau einer derartigen
Architektur? Bisher habe ich nichts brauchbares gefunden.

Viele Grüße
Michael


Hallo Michael

ich bin gleicher Meinung wie du. Ich sehe ein weiteres Problem mit
vielen Assemblies bei z.b. der Versionierung, Rollout etc. Ich würde
auch auf ein logisches Gruppieren setzen. Allerdings kann ich dir dazu
keinen Link zu "Best Practices" angeben ... ist halt eher so ein
Bauchgefühl.


Gruss
Alain

Ähnliche fragen