Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

Tree(Node) Collection als Zwischenschicht bauen [und grundsätzliches zur 3-Schichten-Architektur]
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Nein

beantworten | zitieren | melden

Nachtrag: ich gehe bei diesem Modell davon aus, dass eine mehrschichtige verteilte Anwendung entworfen werden soll, deren Kern-Geschäftslogik in Diensten/Komponenten gekapselt ist und ggf. über entfernte Aufrufe konsumiert werden kann/soll.

Nein! Model, View und Controller gehören alle drei zur GUI. Das Model implementiert NICHT die Geschäftsregeln (Wenn man triviale Dinge nicht als Geschäftsregeln betrachtet), sondern verwaltet nur den temporären Clientstatus (also die Daten die der Benutzer der GUI momentan bearbeitet). Das Model wird über eine Fassade an die benötigten Geschäftskomponenten angebunden (Das Model greift also nur über die Fassade zu). Die Fassade stellt dem Model die Funktionen der Geschäftslogik zur Verfügung, die für diesen Anwendungsfall (use case) benötigt werden. Fassaden erleichtern den GUI-Programmierern im Team die Arbeit und sorgen für weniger Beziehungen zwischen den Komponenten.

Wenn die Geschäftslogik nicht sehr komplex ist, kann man Fassaden auch einfach weglassen (dann redet das Model direkt mit den Geschäftskomponeten).

Das Model ist statuswahrend und liegt immer auf der Maschine, die die GUI bereitstellt. Bei einer Web-Anwendung ist das der Webserver und bei einer Forms-Anwendung der Client-PC. Geschäftskomponenten sind statuslos (d.h. sie speichern keine Daten über mehrere Funktionsaufrufe hinweg).

Die Geschäftskomponenten liegen auf einem Applikationsserver (z.B. Enterprise Services oder ein .NET Remoting Host oder SOAP-Webservices auf einem IIS). Nur die Geschäftskomponenten sprechen mit dem Datenbank-Server. Die GUI spricht mit den Geschäftskomponenten (wahlweise direkt oder über Anwendungsfall-Fassaden).

Meistens wird für jeden Anwendungsfall ein separates Model benötigt. Alle Views die zu diesem Anwendungsfall gehören verwenden das selbe Model. Angenommen Du schreibt eine Lagerbestandsverwaltung. Das Model hält ein DataSet welches die Datesätze der Bestandstabelle des geladenen Artikels enthält. Das UserControl für die Bestandsauskunft in den einzelnen Lagern ist automatisch mit dem Dialog für Bestandskorrekturen synchron. Die Bestandsauskunft aktualisiert sich sogar automatisch, sobald man im Dialog eine Bestandskorrektur vornimmt (Weil sie vom Model über Ereignisse über die Änderungen an den Daten informiert wird). Der GUI-Entwickler kann sich wirklich auf das entwickeln guter Oberflächenelement konzentrieren. Das ist MVC.
private Nachricht | Beiträge des Benutzers
spidermike
myCSharp.de - Member



Dabei seit:
Beiträge: 245

beantworten | zitieren | melden

ok also dann wäre einfach sozusagen die GUI in deinem beispiel folgendermaßen zu gestalten:
- Model wäre also eine klasse, die mit der klasse DisplayFacade kommuniziert und für die beschaffung der daten zuständig ist, sobald sie einen "auftrag" vom controler bekommt
- View wäre dann die GUI also das Form selbst, das events wirft welche vom controler bearbeitet werden
- Controler wäre die klasse die die Baumansicht erstellt, wenn dies die gui so will, und dazu vom model die datenbeschaffung anfordert
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Controller

beantworten | zitieren | melden

Genau, bis auf den Controller. Die Baumansicht ist reine Anzeige und wird deshalb im entsprechenden View (Ich würde ein UserControl schreiben und es auf einer zweiten View, nämlich dem Form plazieren) implementiert.

Der Controller ist das Fugenkit, der die Instanz des Models erzeugt und die Views erzeugt. Er weist jeder View nach dem erzeugen das Model zu (Über die Model-Eigenschaft der IView-Schnittstelle). Jede View implementiert diese Eigenschaft. Beim zuweisen (set) kann die View auch gleich die jenigen Ereignisse des Models abonnieren, die für sie von Interesse sind (Nicht jede View reagiert auf alle Model-Ereignisse).

Auch der Controller kann Ereignisse des Models abonnieren. Man kann über den Controller den Workflow kapseln (z.B. öffnen von Dialogen etc.). Auf diese Art und weise kann man den Workflow des Anwendungsfalls anpassen, ohne alle Views anfassen zu müssen.
private Nachricht | Beiträge des Benutzers
spidermike
myCSharp.de - Member



Dabei seit:
Beiträge: 245

beantworten | zitieren | melden

ok langsam dämmerts immer mehr ...

ich habe verschiedene usercontrols die ich in einer mainform einbaue.

gibts wo eine beispielapplikation die ich mir ansehen könnte, um das zusammenspiel von model-view-controler veranschaulichen zu können?
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Beispiele

beantworten | zitieren | melden

Visual Studio.NET zum Beispiel. Das View "Eigenschaften" zeigt immer die Eigenschaften des ausgewählten Objekts an. Die Dynamische Hilfe zeigt immer Hilfe zu dem Element unter dem Cursor an. Wie können diese Views immer alles genau wissen? Bestimmt weil sie ein gemeinsames Model haben. Deshalb lassen sich auch ganz einfach PlugIns entwickeln.

Wenn sich Zeit habe, schreibe ich mal eine kleine Beispielapplikation.
private Nachricht | Beiträge des Benutzers
spidermike
myCSharp.de - Member



Dabei seit:
Beiträge: 245

beantworten | zitieren | melden

das wäre kuhl, danke ... am besten gleich anhand deines beispiels hier zu beginn =)

irgendwo hab ich gelesen, MVC wäre auch eine architektur ... meine applikation ist unterteilt in forms (also view), geschäftslogik und datenschicht (ms sql db).
dann wird auch MVC pattern im zusammenhang mit model als business logic und view als presentation logic genannt, irgendwie schon verwirrend.
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Ursprung

beantworten | zitieren | melden

Bei einer monolithischen 2 schichtigen Anwendung ist das auch völlig in Ordnung. Das MVC-Pattern stammt aus den 80er Jahren, nämlich von der Sprache Smalltalk-80. Damals waren verteilte Anwendungen in der heute üblichen Form nicht verbreitet. Geschäftslogik und GUI waren nicht in Komponenten aufgeteilt, die verschiedenen Prozessen oder sogar auf verschiedenen Maschinen laufen mussen. Die Geschwindigkeit der damaligen Rechner und der Netzwerke waren auch entsprechend langsam.

Bei Anwendungen die keine Datenbank und zentrale Geschäftsregeln benötigen (z.B. Textverarbeitung) kann diese Aussage (Model = Geschäftslogik) auch heute noch zutreffend sein.

Außerdem sollte man Pattern eher als Richtlinie bzw. allgemeine Konzepte verstehen. Meine Implementierung ist nur eine Möglichkeit. Bis jetzt ist mir nichts besseres unter die Augen gekommen. Wenn man im Web nach MVC sucht, findet man meistens nur allgemeines Blah.
private Nachricht | Beiträge des Benutzers
spidermike
myCSharp.de - Member



Dabei seit:
Beiträge: 245

beantworten | zitieren | melden

Zitat
Original von Rainbird
Meine Implementierung ist nur eine Möglichkeit. Bis jetzt ist mir nichts besseres unter die Augen gekommen.

welche implementierung? das beispiel hier im thread?

und in der grafik dieses beispiels auf
http://www.c-sharpcorner.com/Code/2003/Feb/MVCDesign.asp
wird eine applikation dargestellt, die auch alle komponenten enthält die ich in meinem programm habe ... und sorry, aber genau das ist das verwirrende, hier ist das model wieder business- und data-tier ... irgendwie steh ich auf der leitung glaub ich
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Statusbehaftete Geschäftskomponenten

beantworten | zitieren | melden

Das Beispiel von c-sharpcorner ist mit Fokus auf Webanwendungen ausgelegt. Für Forms-Anwendungen stimmt es nicht, da der Benutzer nicht über den Controller Befehle eingibt, sondern über die Views (z.B. Eingabe in Textbox, klicken auf einen Button etc.).
Zitat
.NET and MVC:

Lets try to find out how closely ASP.NET allows architecting application to meet MVC concept.
Model: Dataset/Business Entities, DataAccess components
View: .ASPX pages

Controller: Code-behind .vb/.cs files

Typed dataset is one of the greatest features in .NET, which holds the application data in memory and represents the application business entity model, which bridges the UI components with Service Interface and Data Access layer.

So, service interface and Data Access components populate these typed Datasets. Now, these filled datasets can be bound to any view in UI layer.

.ASPX and ASCX pages server as view and mean to interface with application, while the code behind classes for these files server as the controller functions.

ASP.NET doesnt have central controller function, instead the code-behind file can directly make request to the Model and can update the dataset. But lot of controller function can be implemented in code behind class events in .aspx or .ascx pages, like Page_Onload(), OnItem_Created() etcevents.

.NET Framework has all Object-oriented features like code reuse, encapsulation etcSo, proper design of your model can make your user interface and view completely separated from model which can server multiple views.

Das deckt sich doch fast genau mit meinem Diagramm unter Trennung von Awendungslogik und Optik
(Man beachte die Seite des Diagramms für Web-Anwendungen)

Ich betrachte das Model als den Teil der Geschäftslogik, der den Clientstatus verwaltet (das entspricht dem Baustein "business entity" im Diagramm von c-harpcorner).
private Nachricht | Beiträge des Benutzers
spidermike
myCSharp.de - Member



Dabei seit:
Beiträge: 245

beantworten | zitieren | melden

alles klar, dann werd ich dich mal nicht länger nerven

falls du noch zeit hast ein kleines beispiel zu posten, oder am besten einfach anhand unseres beispiels hier mit den lieferanten usw. erklären würdest, welches file bei dir (also dienem eingangsbeispiel) als Model, View, Controler etc agiert und was es macht (muss aber nicht gecoded sein) dann bin ich schon zufrieden =)

danke und allen einen schönen wochenbeginn!
private Nachricht | Beiträge des Benutzers
spidermike
myCSharp.de - Member



Dabei seit:
Beiträge: 245

beantworten | zitieren | melden

hallo nochmals,

falls jemand den thread verfolgt hat und mir meinen letzten post-wunsch noch erfüllen kann, wär mir sehr geholfen, ich bräuchte dringend den letzten kick in die richtige richtung um weitermachen zu können

thx!
Mike
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 52329
Herkunft: Berlin

beantworten | zitieren | melden

Hallo spidermike,

Rainbird hat doch schon ein komplettes Beispiel gepostet. Was feht dir denn da noch?

herbivore
private Nachricht | Beiträge des Benutzers
spidermike
myCSharp.de - Member



Dabei seit:
Beiträge: 245

beantworten | zitieren | melden

hey!

hat er schon? meinst das eingangsbeispiel? dachte das wäre eben kein MVC beispiel? 8o
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

beispiel

beantworten | zitieren | melden

Ich habe schon angefangen eine komplette kleine Beispielanwendung mit Access-Db, eigenen Geschäftskomponenten (Zurgiff über .NET Remoting) und einer MVC-GUI zu schreiben. Ist ca. 50% fertig. Ich poste die Solution, wenn alles steht.

Bitte noch etwas Geduld!
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

MVC Beispielsolution ist fertig!

beantworten | zitieren | melden

Die versprochene MVC Beispielanwendung ist fertig!
Attachments
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Screenshot

beantworten | zitieren | melden

So sollte es aussehen:
Attachments
private Nachricht | Beiträge des Benutzers
spidermike
myCSharp.de - Member



Dabei seit:
Beiträge: 245

beantworten | zitieren | melden

ich kann nur sagen vielen dank für deine mühen und die tolle hilfe rainbird ... werds mir gleich anschaun!
private Nachricht | Beiträge des Benutzers
spidermike
myCSharp.de - Member



Dabei seit:
Beiträge: 245

beantworten | zitieren | melden

puh ... gar nicht so leicht hier durchzublicken, zumindest für mich net

ich versuch gerade, meni bisheriges werk zu vergleichen und zu schaun, wo ich was zu ändern hätte, damit aus der GUI daraus ein MVC pattern wird ... hab da manchmal das gefühl, nochmals von vorne anzufangen ginge schneller. *hmpf*
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 52329
Herkunft: Berlin

beantworten | zitieren | melden

Hallo spidermike,

wenn du ein Programm geschrieben hast, in dem Oberfläche und Modell vermischt sind und das du auf MVC umstellen willst, dann *ist* von vorne anfangen schneller.

herbivore
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Komplexität

beantworten | zitieren | melden

Ich musste das Beispiel etwas komplexer machen. Nur in einer Anwendung mit mehreren Views, die auf den selben Datenbestand zugreifen, wird der Vorteil von MVC überhaupt deutlich. Die über .NET Remoting abgetrennten Geschäftskomponenten mussten auch sein. Damit wollte ich aufzeigen, dass Geschäftsregeln bzw. Datenzugriff und Persistenz nicht ins Model gehören.

Was genau hast Du an meinem Beispiel nicht verstanden?
private Nachricht | Beiträge des Benutzers
romu2000
myCSharp.de - Member



Dabei seit:
Beiträge: 299

was passiert wenn....

beantworten | zitieren | melden

hallo zusammen,

was kann denn eigentlich passieren, wenn ich die Abfragen und alles im GUI habe


viele Grüsse

Ronny
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 52329
Herkunft: Berlin

beantworten | zitieren | melden

Hallo romu2000,

aller Voraussicht nach wird das GUI blockieren. Solange im GUI-Thread eine Aktion ausgeführt wird, ist das GUI blockiert.

herbivore
private Nachricht | Beiträge des Benutzers
romu2000
myCSharp.de - Member



Dabei seit:
Beiträge: 299

danke

beantworten | zitieren | melden

jetzt habe ichs verstanden :-)

grüssle

ronny
private Nachricht | Beiträge des Benutzers
_daniel_
myCSharp.de - Member



Dabei seit:
Beiträge: 229

beantworten | zitieren | melden

Hallo,
ich habe mir mal das Beispiel von Rainbird angeschaut.
Gibt es immer nur ein Model für sämtliche Funktionen eines Programms?
Wird das ganze dann nicht schnell etwas unübersichtlich?
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Models

beantworten | zitieren | melden

Es ist nur ein Beispiel. Mehrere Models hätten den Rahmen etwas gesprengt.

Das kommt auf die Anwendung an. Wenn eine Anwendung umfangreich ist, wird auch das Model umfangreich. Bei großen Anwendungen hängt man aber nicht alles an einem Model auf. Man unterteilt die Anwendung in mehrere große Blöcke.

Angenommen ich will ein CRM-System bauen, welches Kunden, Angebote und Projekte verwalten kann. Dazu würde ich zunächst drei Model-Klassen in drei unterschiedlichen Assemblies (DLLs) erstellen. Die könnten z.B. so heißen:
  • CustomerManagement
  • OfferManagement
  • ProjectManagement


Für jedes Model gäbe es natürlich einen eigenen Controler (ein Hauptformular sozusagen) und einige Views. Als Ergbnis habe ich nun drei autonome saubere Module. Aber ich habe noch keine vollständige Anwendung.

Also würde ich noch eine Assembly erstellen (Diesmal eine EXE). Diese würde auch ein Model bereitstellen, welches z.B. CrmApplication heißen könnte. Außerdem natürlich einen Controler (das Anwendendungshauptfenster). In diesem Fenster würde ich die jeweiligen Hauptfenster der drei Anwendungsmodule als Views laufen lassen. Über das Model CrmApplication können die Module kommunizieren. So kann z.B. ein Doppelklick in der Angebotsliste eines Kunden im Kundenformular, das Angebot öffnen, ohne dass das Kundenformular das Angebotsformular kennen muss.

Man muss sich eben ein paar Gedanken über die Architektur der GUI machen, dann wirds auch bei MVC nicht unübersichtlicht.
private Nachricht | Beiträge des Benutzers
_daniel_
myCSharp.de - Member



Dabei seit:
Beiträge: 229

beantworten | zitieren | melden

Hallo,
danke für die Antwort.
Die BusinessComponents (in deinem Bsp OrderManager und SupplierManager) bleiben aber trotzdem alle in einer Assembly oder die dann auch in die Module auslagern und den Datenzugriff wieder in ein getrenntes Assembly (DBHelper ist das glaube ich in deinem Bsp) ?

Wie kann das Kundenformular das Angebotsformular öffnen ohne es zu kennen? Muss da dann noch ein getrenntest Interfaceassembly her oder wie funktioniert das dann?!
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Assemblies

beantworten | zitieren | melden

In einem realen Projekt würde man allgemeine Tools wie DBHelper auf jeden Fall in eine separate Assembly stecken. Ob die Geschäftslogik (OrderManager etc.) in verschiedene Assemblies gepackt wird, hängt von der Größe des Projekts ab. Wenn die komplette Geschäftslogik eh nur auf einem Applikationsserver (Remoting Host) liegt und am Stück deployed wird, macht es keinen Sinn, alles aufzusplitten. Das gibt nur Verweis-Hölle. Wenn man die einzelnen Komponenten auf verschiedenen Applikationsservern betreiben will bzw. Komponenten einzelt deployed werden sollen, ohne dass die anderen angefasst werden (Vielleicht soagr im laufenden Betrieb, wie bei ASP.NET), sollte man die Komponenten in jeweils eigene Assemblies aufteilen.
Grundsätzlich sollte man bei großen Projekten mit vielen Komponenten, diese in größere Bereiche (Kann man gut mit Namespaces abgrenzen) einteilen. Komponenten aus Bereich A sollten nie direkt auf Komponenten in Bereich B verweisen, sondern über die öffentliche Remoting-Schnittstelle gehen. Alles andere führt in den meisten Fällen, zu Nudelsalat. Grundsätzlich sollte man die Geschäftslogik-Assemblies niemals den Clients geben, sondern nur Schnittstellen (In meinem Beispiel habe ich das glaube ich aus Zeitgründen aber nicht gemacht; Es ist ja auch nur ein Beispiel). Für jede Geschäftslogik-Assembly muss es dann logischerweise eine Schnittstellen-Assembly geben. Auch Komponenten aus verschiedenen Bereichen sollten nur über die Schnittstellen miteinander reden.

Zu der Sache mit dem Kunden- und dem Angebotsformular:

Kunden- und Angebotsformular ist im Sinne des Model CrmApplication eine View. Das Anwendungshauptformular ist der Controler für CrmApplication und hat die beiden mit dem Model CrmApplication bekannt gemacht. Wenn das Kundenformular nun ein Angebot öffnen will, muss es sich nur vertrauensvoll an sein CrmApplication-Model wenden:


// Angebot öffnen
_myCrmApplication.OpenOffer(_offerList.SelectedOfferID);
Das CrmApplication-Model feuert aufgrund dieses Aufrufes ein LoadOffer-Ereignis, welches das Anwendungshauptformular fängt:


private void _myCrmApplication_LoadOffer(object sender,LoadOfferEventArgs e)
{
    // Neue Instanz des Angebotsformular erzeugen
    OfferFrom offerView=new OfferForm();

    // Instanz mit Model bekannt machen
    offerView.Model=_myCrmApplication;

    // Instanz zur Auflistung der offenen Angebotsviews zufügen
    _offerViews.Add(e.OfferID,offerView);

    // Angebot laden und anzeigen
    offerView.Open(e.OfferID);
    offerView.Show();
}
Auf diese Weise entkoppekt ein Controler bei MVC die Views voneinander.
private Nachricht | Beiträge des Benutzers
Tokka
myCSharp.de - Member



Dabei seit:
Beiträge: 108
Herkunft: Hamburg

beantworten | zitieren | melden

Hi!

@Rainbird: Vielen Dank für das klasse Beispiel. Hat mir wirklich geholfen.

Was müsste ich bei deinem Beispiel beachten, wenn

3 Clients auf die BL (und darüber auf die DAL) zugreifen, die auf einem Extra Server liegt? Gibt es probleme bei parallelen Zugriff??


Gruß
Tokka
Was einmal war, wird nie wieder sein...
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Parallelzugriffe

beantworten | zitieren | melden

Meinst Du mit Extra Server den Datenbank Server (SQL Server, Oracle etc.) oder einen separaten Applikationsserver für die Datenzugriffslogik?

Geschäftslogik und Datenzugriffslogik auf zwei Applikationsserver aufzuteilen ist nicht unbedingt sinnvoll. Die Server müssen ja über TCP/IP miteinander reden. Natürlich greifen auch die Clients über TCP/IP zu. Bei zwei Applikationsservern (Einer für BL und einer für DAL) sind die Antwortzeiten beim Client um einiges länger, als bei einem zentralen Applikationsserver (DAL und BL auf diesem einen Server).

Bei zwei Applikationsservern läuft die Kommunikation so ab:
  • Der Client ruft via TCP einen Dienst auf dem BL-App-Server auf
  • Der BL-App-Server besorgt sich via TCP die Daten vom DAL-App-Server
  • Der DAL-App-Server kommuniziert mit dem Datenbankserver

Die Daten müssen also zwei Mal übers Netzwerk geschoben werden. Das sollte man bedenken. Bei einem zentralen Applikationsserver fällt ein "Netzwerk-Hop" weg.

Trotzdem muss es nicht schlecht sein, die Schichten wirklich auf verschiedene Server aufzuteilen. Ich würde allerdings eher einzelne Dienste komplett (Jeweils mit BL und DAL) auf verschiedene Server verteilen. Das kommt auf den Anwendungsfall an. Allerdings sind zwei Applikationsserver für nur 3 Clients ziemlich überdimensioniert. Selbst bei Installationen mit 50 oder mehr Benutzern ist ein einzelner Applikationsserver meistens völlig ausreichend (Ausgehend von Standard-Business-Anwendungen, die mit Daten wie Kundeninfos, Angeboten etc. hantieren).

Was Parallelzugriffe betrifft, sollte es bei SingleCall-Aktivierung keine Probleme geben. Die Objekte leben nur für einen Methodenaufruf. Jeder Methodenaufruf von einem Client wird in einem separaten Thread ausgeführt. Bei fünf gleichzeitigen Client-Zugriffen sind das fünf Threads. Auch bei Singleton-Aktivierung läuft jeder Client-Aufruf in einem eigenen Thread. Allerdings verwenden alle Clients das selbe Objekt (und damit auch die selben Variableninstanzen). Bei Singleton-Aktivierung muss man also IMMER threadsicher programmieren.

Damit auf der Datenbank alles konsistent bleibt, sollte man alle schreibenden Operationen in Transaktionen ausführen (Namensraum System.Transactions).

Grundsätzlich ist es egal, auf wie viele Server Du welche Logik aufteilst. Das Prinzip ist immer das selbe. Man muss Vor- und Nachteile der möglichen Szenarien gegeneinander abwägen.
private Nachricht | Beiträge des Benutzers
Tokka
myCSharp.de - Member



Dabei seit:
Beiträge: 108
Herkunft: Hamburg

beantworten | zitieren | melden

Vielen Dank für deine Ausführliche Antwort.

Die BL und DAL werde zusammen auf dem SQL-Cluster liegen.
Das ganze auf 2 Separate Maschinen aufzuteilen ist nur ein Gedanke, den ich im Hinterkopf habe... (Bei Java habe ich ja den AS und den DB-Server).


Natürlich werden nicht nur 3 Clients eingesetzt, es ging mir ja ehr nur um die Parallälität. So wie es aussieht, wird die GUI auf ca 900 Clients laufen.

Nochmals vielen Dank. Nun können wir uns mehr darunter vorstellen und das Konzept verfeinern!

Gruß
Tokka
Was einmal war, wird nie wieder sein...
private Nachricht | Beiträge des Benutzers