MVC (analog zu Java) in .NET?
[EDIT]Abgeteilt von Alle Oberflächenelemente eine Form auslesen[EDIT]
Wo wir gerade dabei sind:
In Java wurde ja das MVC-Konzept (Model View Controller) im Package "Swing" umgesetzt, die Oberflächenelemente da (Tabellen, Listboxes etc.) funktionieren von vorn herein nach diesem Prinzip.
Gibt es das auch für Visual C#? Von dem, was ich bisher mitbekommen habe, muss man hier sein eigenes MVC programmieren...
Hallo Zuiop,
vielleicht kann dir MVC# weiterhelfen.
MVC# - is a Model-View-Presenter framework for .NET platform. It allows taking advantage of the MVP pattern with minimal effort required. As a result applications gain 3-tier structure, become better structured and easier to maintain.
Gruß,
David
Hallo schaedld,
kleiner Hinweis: es geht hier bzw. in dem Thread, in dem du ursprünglich gepostest hast, um Windows.Forms, nicht um ASP.NET.
herbivore
kleiner Hinweis: es geht hier bzw. in dem Thread, in dem du ursprünglich gepostest hast, um Windows.Forms, nicht um ASP.NET. Sorry... OK das MVC Pattern kann man ja fast eins zu eins übernehmen...
Grüsse
Daniel
Space Profile
Wer nicht fragt, der nicht gewinnt
Könnte aber jemand trotzdem etwas zu WindowsForms posten. Weil genau die Information ist nämlich nirgends zu finden und die brauche ich ebenfalls.
Liebe Grüsse
hobold
Hallo hobold,
vermutlich stellst du dir vor, dass es eine Standard-Vorgehensweise "MVC für Windows.Forms" gibt. Weit gefehlt. Es gibt kaum ein Muster, für das es mehr Varianten und Variationen gibt als MVC. Davon ist abgesehen ist es schwer und gleichzeitig nicht sinnvoll, MVC reinen Wassers für Windows-Forms zu implementieren. Eine eigenständige Controller-Klasse bringt einem unter Windows-Forms z.B. nichts bzw. stört nur. Du wirst nicht drum rum kommen, dir die verschiedenen Links anzusehen und auch noch selber zu suchen und dann selber zu entscheiden, wie du es machen willst.
herbivore
Hi,
bei MVC# gibt es doch ein Beispiel für die Implementation mit WinForms.
Using the Windows Forms views engine in MVC# framework
Gruß,
David
Danke herbivore,
Mir ist schon klar, dass es sehr viele Umsetzungen von MVC geben wird. Aber der grundsätzliche Aufbau wird doch identisch sein oder nicht? Wieso dann ein Pattern, wenn es sich dann doch komplett anders verhält und aufgebaut ist.
Eine kleine Grundapplikation (damit man es leicheter versteht) und ohne zusätzlichem Framwork wird es doch geben oder nicht?
Ich meine allein schon was mach ich mit der WindowsForm? Normalerweise gibt es doch eine Program.cs in der durch Application.Run(new Form()) ein neuer Form erzeugt wird. Wie baue ich jetzt einen neuen Controller ein, der sich um alles kümmert.
Wie werden Änderungen vom Model dem View mitgeteilt usw.
Ich weiß, dass klingt so nach: Ich bin faul und möchte mir nicht alles durchlesen, aber es ist nicht so. Es schwirren nur so viele unterschiedliche Lösungen im Web, manche haben meiner Meinung nach überhaupt nichts mit MVC zu tun, obwohl behauptet und die meisten nutzen überhaupt keine Windows.Form.
Vielleicht kannst du mir ja mit weiterem Input helfen.
Vielen Dank,
lg hobold
Hallo hobold,
Aber der grundsätzliche Aufbau wird doch identisch sein oder nicht?
nein, wie schon gesagt, da gibt es viele verschieden Varianten. Eine der wichtigen Entscheidungen ist aktive oder passive MVC. Das macht dann schon einen ziemlich großen Unterschied. Es gibt aber noch weitere Unterteilungen.
Wieso dann ein Pattern, wenn es sich dann doch komplett anders verhält und aufgebaut ist.
Der unveränderte (original) Pattern konnte anscheinend nicht die verschiedensten Anforderungen abdecken. Deshalb sind im Laufe der Zeit immer weitere Varianten entstanden.
Eine kleine Grundapplikation (damit man es leicheter versteht) und ohne zusätzlichem Framwork wird es doch geben oder nicht?
Es gibt eben viele verschiedene. Wenn du eine beliebige willst, nimm Zugriff auf Steuerelement aus Klasse. Auch das ist letztendlich (eine Variante des) MVC-Pattern.
Vielleicht kannst du mir ja mit weiterem Input helfen.
Noch mehr Input wäre ja kontraproduktiv. Wie du selber schreibst:
Es schwirren nur so viele unterschiedliche Lösungen im Web
Da brauchst du eigentlich nicht noch eine weitere Lösung von mir.
Nimm stattdessen meinen Rat von oben:
Du wirst nicht drum rum kommen, dir die verschiedenen Links anzusehen und auch noch selber zu suchen und dann selber zu entscheiden, wie du es machen willst.
Nur du kannst wissen, was für dich das beste ist. Wenn du das noch nicht weißt, musst du die verschiedenen Ansätze ausprobieren. Der Ansatz, der für mich am besten ist, liegt dir vielleicht gar nicht. Und umgekehrt. 🙂
herbivore
Danke, ich versuch mal deinen Tipp umzusetzen.
lg hobold
Hallo nochmals,
irgendwie komme ich nicht weiter, wie ich einen MVC für C# hinkriegen bekomme.
Tut mir leid, falls ich nerve.
lg hobold
Hallo hobold,
ich habe doch oben konkreten Code verlinkt. Was stört dich an dem?
Dass View und Controller nicht getrennt sind? So eine Trennung ist bei Windows Forms - und du willst ja extra MVC für Windows Forms - nicht sinnvoll.
Man kann die View- und die Controller-Anteile aber immer noch als solche identifizieren. Zum View gehört die Form selber sowie die anzeigenden Controls (ListBox, ListView, ...). Zum Controller gehören die Controls für Benutzerinteraktionen (Buttons, Menüs, ...) sowie alle EventHandler, die auf Benutzerinteraktionen reagieren (z.B. button1_Click).
Der Übergang zwischen View- und Controller-Controls ist bei vielen, wenn nicht allen Controls fließend. So dient eine ListBox im Wesentlichen der Anzeige von Daten (View), kann aber auch bei einem Doppelklick auf eine Zeile eine Aktion aufrufen (Controller). Ein Button wird meistens eine Aktion auslösen (Controller), aber seine Beschriftung könnte sich je nach Status ändern (View).
Das ist einer der Gründe, warum es unter Windows Forms nicht sinnvoll ist, View und Controller zu trennen.
Ein weiterer Grund ist das Prinzip der Ereignissteuerung, quasi das zentrale Steuerungsprinzip der Anwendung, auf Ereignisse (z.B. in Form von Benutzerinteraktionen) zu reagieren. Damit entfällt aber (zumindest bei normalen Business-Anwendungen) die Notwendigkeit, dass der Controller die Anwendung steuert. Eine wichtige Aufgabe des Controller (die zentrale Steuerung zu realisieren) entfällt damit.
Im Resultat ist der verlinkte Code eine gute Umsetzung des MVC-Pattern für Windows Forms. Natürlich könnte man auch DataBinding verwenden. Das würde dem Prinzip, in der GUI möglichst wenig Logik zu haben, entgegenkommen.
Natürlich kennt bei diesem Ansatz das View immer noch das Modell. Auch das kann man entkoppeln. Das nennt sich dann z.B. Passive View. Das View ist dann noch dümmer und lässt sich noch leichter auswechseln. Allerdings um den Preis aufwändigerer Handhabung und dadurch von mehr Code.
Was stellst du dir denn vor?
herbivore
ok ich verstehe deinen Gesichtspunkt. Unterschiedliche MVC Realisierungen, die an die eigenen Bedürfnisse angepasst sind.
Nur MVC soll ja, eine wiederverwendbare Architektur sein, die ein wiederkehrendes Problem löst und da muss es wirklich eine kleines Grundgerüst geben. (Das ich jetzt auch habe, nach Tagen an Recherche und Try and Error). Und das hätte ich benötigt.
Solltest du dich auf den Schlipps getretten fühlen, so entschuldige. Vielleicht ist meine Denke falsch, aber die Beispiele waren mir alle einzeln irgendwie unbegreiflich.
Danke für die Hilfe
hobold
Hallo hobold,
Das ich jetzt auch habe, nach Tagen an Recherche und Try and Error
dann mal her damit 🙂
herbivore
Da ich mich mit dem Thema schon des öfteren intensiv auseinandergesetzt habe, möchte ich jetzt auch mal meinen Senf dazugeben:
Das ist einer der Gründe, warum es unter Windows Forms nicht sinnvoll ist, View und Controller zu trennen.
Dem kann ich nicht direkt zustimmen. Es kommt eben auch darauf an wie man den Begriff Controller definiert. Ich sehe den Controller als die Komponente in der sich die tatsächliche Business Logik befindet z.B. sowas in der Art: AddCustomer(Customer customer). Von diesem Gesichtspunkt aus macht es sehr wohl Sinn hierfür
einen eigenständigen Controller zu haben um Logik und Design zu trennen.
Man kann das ganze dann noch weiter treiben und bei den Controller Methoden
verschieden aufrufen z.B.
AddCustomer(Customer customer)
{
......
ICustomerService.AddCustomer(customer)
.....
//Model aktualisieren
//View aktualisieren
}
Die View enthällt bei mir nur die EventHandler in denen dann Methoden vom Controller aufgerufen werden.
Ich bin jetzt jedoch dazu übergegangen auf das MVP Pattern umzusteigen, da ich denke dass dies für die heutigen Anwendungen besser geeignet ist. Hier hat man ebenfalls eine klare Trennung zwischen View und Controller (hier Presenter).
Der Presenter hat hierbei über ein definiertes Interface Zugang zur View. Ist aber durch das Interface von der konkreten Implementierung abstrahiert. Bei MVP ist aber im Normalfall keine Verbindung von der View zum Model.
Die komplette Kommunikation findet über den Presenter statt. Dies vereinfacht die Implementierung gegenüber dem normalen MVC.
Hallo jnetrick,
was du Controller nennst, ist das Modell. Und die Trennung zwischen View und Modell ist natürlich sinnvoll. Das ändert aber nichts daran, dass es unter Windows-Forms nicht besonderen sinnvoll ist Controller und View zu trennen.
herbivore
Das kommt darauf an wie flexibel die zu erstellende Anwendung sein soll.
Wenn es grundsätzlich vorgesehen ist, die Controller Logik für Windows Forms, WPF oder WebForms oder irgendeine andere View-Technologie zu verwenden,
muss man sich für die Controller Komponente etwas einfallen lassen um diese von der Form Klasse zu trennen.
Das Model enthällt normalerweise nur die Daten der View und je nach dem wie man es implementiert die Logik zum abrufen der Daten.
Hier nochmal meine Interpretation:
View:
nur Darstellungs und GUI Logik z.B. Farbe eines Items ändern, wenn Wert X=5
Model:
Daten die in der View dargestellt werden.
Controller:
Ausführung der Business Logik z.B. AddCustomer(Customer customer)
Die Synchronisierung von Model und View kann auf verschiedene Art und Weise durchgeführt werden z.B. Observer Pattern, DataBinding
bei
MVP hat das Model überhaupt keine Verbindung mehr zur View und die Synchroniserung der Daten läuft über den Presenter
Wenn man die Komponenten sauber voneinander trennt hat man die größtmögliche Flexibilität und kann jederzeit Model View oder Controller durch eine andere Implementierung austauschen.
Hallo jnetrick,
Das Model enthällt normalerweise nur die Daten der View
dann programmierst du aber daten- aber nicht objektorientiert.
Hier nochmal meine Interpretation: ...
Diese Interpretation halte mindestens für ungewöhnlich und ungünstig.
Wenn man die Komponenten sauber voneinander trennt hat man die größtmögliche Flexibilität und kann jederzeit Model View oder Controller durch eine andere Implementierung austauschen.
Das ist klar. Und das ist auch der Grund, warum möglichst alles im Modell und möglichst wenig im GUI-Teil (egal ob nun Controller oder View) stecken sollte. Das Modell soll ja in der Regel gleichbleiben, während das GUI getauscht werden können sollte.
Unabhängig davon kostet die Flexibilität natürlich auch. Man muss also auch aufpassen, dass man es nicht übertreibt. Eine gute Struktur ist wichtig. Aber zuviel Flexibilität ist (fast) genauso schlecht wie zu wenig.
herbivore
Ich finde zu dem Thema die Artikel von Martin Fowler ganz interessant
http://www.martinfowler.com/eaaDev/uiArchs.html
Man kann das MVC Pattern natürlich auf verschiedene Art und Weise implementieren.
Wo sich die Business Logik befindet ist tatsächlich umstritten (Model vs. Controller).
dann programmierst du aber daten- aber nicht objektorientiert.
Dass sich im Model die Daten befinden die im View dargestellt werden war schon bei SmallTalk so und SmallTalk ist die Objektorientierte Programmiersprache schlechthin und alle GUI Controlls wurden hier zum ersten mal nach dem MVC Patter implementiert.
Ich bin mit meiner Vorgehensweise bisher eigentlich immer ganz gut gefahren, lasse mich aber auch eines besseren belehren. Deshalb würde ich mich freuen wenn noch mehr Leute Ihre Erfahrungen und Interpretationen zu MVC posten würden.
Unabhängig davon kostet die Flexibilität natürlich auch. Man muss also auch aufpassen, dass man es nicht übertreibt. Eine gute Struktur ist wichtig. Aber zuviel Flexibilität ist (fast) genauso schlecht wie zu wenig.
Dem kann ich nur zustimmen, zumal manchmal eine zu hohe Flexibilität nicht vom zur Verfügung stehenden Budget gedeckt wird.
Hallo jnetrick,
Dass sich im Model die Daten befinden die im View dargestellt werden war schon bei SmallTalk so ...
klar. Es geht ja auch nicht um das Vorhandensein der Daten, sondern um die Abwesenheit von Businesslogik, durch die aus Objektorientierung Datenorientierung wird. 🙂 Wobei Datenorientierung ja auch nichts schlechtes ist. Nur ist es eben m.E. besser, ja fast schon zwingend die BusinessLogik ins Modell zu packen. Die einzige Ausnahme, die ich davon sehe, ist der Teil der Business-Logik, den man Workflow nennt.
herbivore
Hallo, ich möchte hier auch noch meinen Senf dazu geben 🙂
Hier nochmal meine Interpretation:
...
Controller:
Ausführung der Business Logik z.B. AddCustomer(Customer customer)
Diesen Ansatz halte ich ehrlich gesagt für falsch. Ein Controller ist dazu da, dem Model Anweisungen zu geben, was es machen soll.
In meinem Fall sieht das so aus, dass das Model öffentliche parameterlose(!) Methoden zur Steuerung bereitstellt, die der Controller dann aufruft.
Alles weitere ist dann Aufgabe des Models. Die Kommunikation zwischen View und Model stelle ich durch Events dar, die vom Model bereitgestellt werden und der View abboniert. Als Reaktion auf ein Event von einem Model holt sich der View dann z.B. die entsprechenden Daten aus dem Model.
Diesen Ansatz halte ich ehrlich gesagt für falsch. Ein Controller ist dazu da, dem Model Anweisungen zu geben, was es machen soll.
In meinem Fall sieht das so aus, dass das Model öffentliche parameterlose(!) Methoden zur Steuerung bereitstellt, die der Controller dann aufruft.
Das hört sich nicht schlecht an. Allerdings glaube ich nicht, das es hierbei ein richtig oder falsch gibt. Bei den Artikeln die man zu der Thematik findet
ist meistens nicht klar definiert wo sich die Business Logik der Anwendung befindet
bzw. habe ich es so interpretiert, diese in den Controller zu legen. Falls jemand gute Artikel zu dem Thema kennt. Immer her damit 🙂
Die Kommunikation zwischen View und Model stelle ich durch Events dar, die vom Model bereitgestellt werden und der View abboniert. Als Reaktion auf ein Event von einem Model holt sich der View dann z.B. die entsprechenden Daten aus dem Model. Das mache ich genauso...
Hallo jnetrick,
"falsch" halte ich auch für das falsche Wort. Aber es ist zumindest sehr ungünstig und daher nicht zu empfehlen. Da man den Controller neuschreiben oder zumindest ändern muss, wenn das das (G)UI austauscht wird, sollte er so einfach wie möglich sein und so wenig wie möglich Logik enthalten. Alle GUI-unabhängige Logik gehört sinnvollerweise ins Modell und nicht in den Controller.
herbivore
Aber es ist zumindest sehr ungünstig und daher nicht zu empfehlen. Da man den Controller neuschreiben oder zumindest ändern muss, wenn das das (G)UI austauscht wird, sollte er so einfach wie möglich sein und so wenig wie möglich Logik enthalten
Die View kann bei mir nur über ein Interface auf den Controller zugreifen. Es ist also kein Problem den Controller einfach auszutauschen. Der Controller kann bei mir von verschiedenen Views verwendet werden.
Hier nochmal ein Beispiel:
public partial class CustomerView: Form, ICustomerView {
public ICustomerPresenter Presenter {
get;
set;
}
[ObservableUpdate]
public void Update(ICustomerModel observable, ObservableEventArgs args) {
//...
}
private void AddCustomerButton_Click(object sender, EventArgs e) {
Presenter.AddCustomer(this.CustomerIdTextBox.Text, this.CustomerNameTextBox.Text);
}
}
Hallo jnetrick,
dass der Controller unterhalb des Views liegt, ist mindestens ungewöhnlich. Eigentlich soll der Controller die ganze Anwendung steuern, inkl. des Views und deshalb darüber liegen. Ich verstehe nicht, was du mit einer solchen Schicht zischen View und Modell erreichen willst. Pack die Logik deines "Controllers" besser in das Modell und lass das View direkt darauf zugreifen.
herbivore
Mit diesem Thema schlage ich mich auch schon eine Weile herum. Es geht um die Entmüllung mehrerer Forms, die 5000+ Zeilen haben, weil alles von Optik über Berechnungen, Daten, Geschäftslogik und DB Zugriffe komplett in diesen Forms enthalten sind. Hier sollen grundsätzlich die verschiedenen, verklebten Schichten gelöst werden.
Trotzdem oder gerade deshalb kämpfe ich gegen eine gute Lösung an.
Mein Ansatz bisher:
- ein Klasse, die die Form kennt. (ChefBL). ChefBL kennt:
- mehrere Klassen, die sich um Berechnungen etc. kümmern, thematisch gruppiert.
- benötigen diese Daten, haben sie Zugriff auf eine/mehrere Klassen, die die Db-Zugriffe verwaltet. (der DalChef).
Ich grüble nun, ob das wirklich sinvoll ist:
Was mache ich mit den ganzen Datasources/Bindingsources, die, im FormDesigner verankert, momentan fröhlich kreuz-und-quer direkt auf diverse (proprietäre) DB-Objekte zugreifen? (auf Properties des ChefBls umlegen?)
Lohnt sich der Aufwand mit einer ChefBL-Klasse? (Viele Methodenaufrufe werden einfach an die spezialisierten Klassen durchgereicht...)
Alles garnicht so einfach. =)
OUT! OUT! You demons of stupidity!
-Dogbert
Hallo lindan,
die Trennung zwischen GUI und Modell ist bei so großen Projekten sicher sinnvoll und wichtig.
Ob es ein ChefBL-Klasse geben sollte weiß ich nicht, vermutlich eher nicht. Keinesfalls sollte diese Klasse jedoch auf das Form zugreifen. Der BL sollte noch nicht mal was von den Forms wissen, geschweige denn darauf zugreifen.
mehrere Klassen, die sich um Berechnungen etc. kümmern, thematisch gruppiert.
Das ist kein objektorientierter Ansatz. Klassen werden nicht nach den Berechnungen gruppiert, sondern nach den Daten, genauer eben nach den Objekten, also sowas wie Versicherter, Adresse, Vertrag.
Was mache ich mit den ganzen Datasources/Bindingsources, die, im FormDesigner verankert, momentan fröhlich kreuz-und-quer direkt auf diverse (proprietäre) DB-Objekte zugreifen?
Auch die Datenzugriffe sollte alle in eine eigene Schicht (DAL). Nachher hast du also folgendes: GUI -> BL -> DAL.
herbivore
Herbivore, zunächst danke für die Antwort.
die gui-bl-dal Geschichte ist prinzipiell soweit klar.
Es hakt ein wenig an der Praxis. Nehmen wir als Beispiel mal eine Combobox. Diese wurde vom ursprünglichen Erfinder im FormsDesigner per Bindingsource an ein Datenbankobjekt gehängt.
Sowohl das Datenbankobjekt, als auch die Bindingsource hängen nun im Form-Code. Wie entzerre ich das am besten?
Lasse ich die bindingsource in der Form, die dann als Datasource eine Property aus der bl-klasse hat, die sich die das Datenbankobjekt aus dem dal bekommt?
Oder ist das unpraktisch? Manche Forms können bis zu 30 dieser Bindings haben...
Es sind diese "kleinen" Entscheidungen, die den Weg zum Großen Ganzen verkomplizieren... kopfkratz
OUT! OUT! You demons of stupidity!
-Dogbert
Hallo lindan,
die erste Entscheidung, die du zuerst treffen musst, ist, ob du im BL direkt mit DataSets (DS) oder typisierten DataSets oder mit Business-Objects (BO) arbeiten willst. Dazu gibt es unterschiedliche Ansichten. Bei Programmen, die kaum innere Logik haben, sondern nur zur Anzeige, Änderung und Speicherung von Daten dienen, kann es unnötiger Aufwand sein, die Daten zusätzlich aus DS in BOs umzukopieren und beim Speichern wieder zurück. Anderseits wird das ganze Programm erst so richtig objektorientiert, wenn man die eigentliche Logik zusammen mit den Daten in eigene BOs packt. Aber wie immer du dich entscheidest, kannst du natürlich immer DataBinding verwenden. DataBinding funktioniert auch für BOs. Wenn du dich also für BOs entscheidest ...
Lasse ich die bindingsource in der Form, die dann als Datasource eine Property aus der bl-klasse hat,
... ist das ok, ...
die sich die das Datenbankobjekt aus dem dal bekommt?
... aber das DS aus dem DAL sollte im BL dann nicht mehr auftauchen. Die Property des BOs sollte also einfach den passenden Wert liefern, aber kein DS.
herbivore
Gui/BL soweit ok.
Ein Problem was ich noch sehe ist, dass die Datenzugriffsobjekte momentan über ein OR-Mapper-ähnliches Tool generiert werden. Es ist im Gespräch, dieses Tool mittelfristig gegen ein anderes zu ersetzen.
Um zu verhindern, dass der bl am Tag X zusammenbricht, will ich ihn von diesen "gefährlichen" Db-Objekten abnabeln.
Gehe ich recht, dass ich dazu die konkreten dal-Klassen hinter entsprechenden Interfaces verstecken muß?
Ich hätte dann, bezogen auf eine der Monsterforms, eine Struktur in der Art ("leicht" vereinfacht ausgedrückt):
formX
|
blFormX
|
----InterfaceDalFormX
|
dalFormXImplementation
Right?
OUT! OUT! You demons of stupidity!
-Dogbert
Hallo lindan,
klar kannst du ein Interface verwende. Aber in vielen Fällen wird es ausreichen, einfach DataSets zur Entkoppelung zu verwendet. DataSets sind ja eine sehr allgemeine Klasse, von der man immer die passenden Objekte liefern kann, egal auf welche Weise die Daten tatsächlich gespeichert und geladen werden.
herbivore
Die (versprochen) letzte blöde Frage:
Könnte ich statt Datasets auch IBindingLists nehmen? Oder ist das schon wieder zu speziell?
OUT! OUT! You demons of stupidity!
-Dogbert
Hallo lindan,
kommt mir erstmal komisch vor. Was soll denn in den Listen enthalten sein?
herbivore
Momentan ist es so, dass an vielen Comboboxen (typisierte) Collections von typisierten Objekten hängen.
Im Code werden häufiger Datasources umgehängt.
Bsp:
Die Form will die DataSource für eine Combobox aktualisieren.
Sie macht in etwa folgendes(ist ja alles in einem, die Dbobjekte/Methoden sind vorgeneriert)
cbBoxBindingSource.Datasource = dbKfzTabelleAbfrageObjekt.GetAutos(Parameter);
diese Methode liefert eine dbKfzTabelleAutoCollection zurück, die n Objekte vom Typ dbKfzTabelleAutos enthält.
Alle möglichen Boxen verwenden alle möglichen Db-Objekte und Collections, alle mit dieser Syntax. Nun bin ich unsicher, wie ich das krisensicher in ein DataSet bekomme, weiß aber, dass diese ganzen Collections IBindingList implementieren.
[Ein kurzer Test hat bestätigt dass ich die Dinger einfach in IBindingList casten kann]
WARUM alle naslang die Datasources neu angehängt und umgewandelt werden, hat sich mit noch nicht genau erschlossen, das geht sicher auch eleganter. Aber so ist es nunmal im Moment. 🙁
OUT! OUT! You demons of stupidity!
-Dogbert
Hallo lindan,
Momentan ist es so, dass an vielen Comboboxen (typisierte) Collections von typisierten Objekten hängen.
... für mich klingt das nach einem Widerspruch zu ....
Alle möglichen Boxen verwenden alle möglichen Db-Objekte und Collections, alle mit dieser Syntax. Nun bin ich unsicher, wie ich das krisensicher in ein DataSet bekomme, weiß aber, dass diese ganzen Collections IBindingList implementieren.
Du musst doch schon entscheiden, ob du im BL mit typisierten Objekten oder DataSets arbeiten willst. Mixen solltest du das nicht.
WARUM alle naslang die Datasources neu angehängt und umgewandelt werden, hat sich mit noch nicht genau erschlossen,
Das solltest du erstmal herausbekommen, ansonsten ist es schwer zu helfen.
herbivore
interessanter thread.
komme ebenfalls aus dem java/swing umfeld. arbeite seit einem jahre mit .net und finde die gui-klickerei immer noch total nervend. irgendwie ergibt sich da kein arbeitsfluss. maus und tastatur wechseln sich dabei ab, bis man sehnenscheiden entzündung hat. mir ist der swing ansatz mit den panels und den layoutern vieeeeel sympthischer. es lässt sich damit auch viel einfacher eine domänen spezifische gui aufbauen. also ein gui-framework mit dem der entwickler davon befreit wird, wie er die gui gestaltet (beinahe befreit).
bei .net besteht die gefahr dass jeder so ein bisschen macht was er grad lust hat.
mvc ist irgendwie bei microsoft eh so ein bisschen unbekannt. bei asp.net machen sie endlich mal was. (30jahre nach smaltalk 🙂 )
ich bin zur zeit auch am bauen eines framework. bin noch hin und her gerissen zwischen forms und wpf.
vermutlich dann wpf weil zukunftsmusik.
cheers
Du musst doch schon entscheiden, ob du im BL mit typisierten Objekten oder DataSets arbeiten willst. Mixen solltest du das nicht.
Ich werde versuchen mich präziser auszudrücken.
Der IST-Zustand ist, das an den Comboboxen typisierte Listen hängen. Die Typen dieser Listen und der Typ der enthaltenen Db-Objekte wurden von einem DbTool, dass die Datenbank gescannt hat, generiert.
SOLL-Zustand ist, dass ich diese direkte Kopplung sprengen will. Ein getrennter BL im eigentlichen Sinne existiert momentan nicht.
Zur Abfrage der Datenbank muß ich momentan weiterhin die generierten Db-Objekte verwenden. Mein BL soll im Prinzip das machen, was du auch gesagt hast: über ein Interface, Datasets o.ä. gui und db entkoppeln.
Viele der Dbobjekte geben ausschliesslich typisierte Listen zurück.
Frage ist nun: was tun?
OUT! OUT! You demons of stupidity!
-Dogbert
Hallo lindan,
Frage ist nun: was tun?
hm, du hast doch genau beschrieben, was du tun willst. Was hindert dich?
herbivore
Mir fehlt der goldene Einzeiler, um den Inhalt einer IBindingList in eine Datatable/Dataset umzuverpacken. 😉
OUT! OUT! You demons of stupidity!
-Dogbert
@lindan:
Wozu?
Lass es auf IBindingList(View), denn das umkopieren ist unsinnig.
Schau dir lieber mal an, wie man dann MVP, also Presenter und PassivView implementiert.
Dein View stellt nach aussen die DataSource und DisplayMember zur Verfügung,
ausserdem die ChangedEvents, Nichts weiter.
Der Presenter ist zuständig für das besorgen der richtigen Liste, und anhängen an
die entsprechenden Properties, und Verarbeitung der entsprechenden Daten.
Du kannst dann verschiedene Presenter und auch verschiedene Views implementieren, die dann die verschiedenen Eventualitäten abdecken.
@HappyLil:
Es zwingt dich niemand mit der Mouse zu arbeiten.
Man kann in .NET genauso arbeiten, und mit den Table/FlowLayoutPanels auch
ähnlich vorgehen.
Und mit Frameworks wie CAB/SCSF oder seinen WPF pendants ist es alles kein wirkliches Problem.
Aber wenn man immer alten Zeiten hinterherweint......
@fzelle
taugt die cab geschichte was? arbeitest du damit?
Ja, Ja.
Man muss allerdings das SW design an CAB/SCSF anlehnen, und kann nicht
einfach jedes xbeliebige projekt gleich damit umbauen.
Es ist halt die Grundlage für ein System.
Wenn du dann allerdings mal das mit den Workitems, den EventBroker,
ServiceBroker usw verstanden hast, ist es schon eine grosse erleichterung.
@lindan:
Wozu?
Lass es auf IBindingList(View), denn das umkopieren ist unsinnig.Schau dir lieber mal an, wie man dann MVP, also Presenter und PassivView implementiert.
Dein View stellt nach aussen die DataSource und DisplayMember zur Verfügung,
ausserdem die ChangedEvents, Nichts weiter.Der Presenter ist zuständig für das besorgen der richtigen Liste, und anhängen an
die entsprechenden Properties, und Verarbeitung der entsprechenden Daten.Du kannst dann verschiedene Presenter und auch verschiedene Views implementieren, die dann die verschiedenen Eventualitäten abdecken.
Will do. Ich schaue mir das heute mal aus der Nähe an und melde mich mit Fangfragen aller Art zurück. Danke für die Antworten. =)
OUT! OUT! You demons of stupidity!
-Dogbert