Signals einfach Mal anbieten oder nicht?
-
ich bin doch der eine wo hinrissige kommentare macht
-
Also klar, in einer lokalen Applikation wird man wahrscheinlich keine Probleme haben, die Controller untereinander irgendwie zu handhaben. Aber bei einer verteilten Multi-User-Anwendung würde man dann eine spezielle und einzigartige Controller-Klasse-Instanz über das Model pflanschen, mit der sich die Client-Controller unterhalten... Weiß halt nicht inwiefern das Sinn macht.
Ich habe in einer meiner Anwendungen mal ein Message-System verwendet, statt explizite Observer zu verwenden. Dann wurde pro Modell ein Satz von Nachrichten definiert und es gab einen geteilten Message-Bus, auf dem jeder mithören und sich die Nachrichten (mit Hilfe von vereinfachenden Mixins) rausfiltern konnte, wie es ihm beliebte. So habe ich mir ne Menge Observer und/oder Slot-Schmu gespart. Praktisch ein Software-interner Kommunikationsbus. Hat auch geklappt, war aber halt viel hinter templates verstecktes gecaste, das jetzt nicht unbedingt jedem hardcore c++ler gefällt.
-
Shade Of Mine schrieb:
und @mechanis: signal/slot ist ein Konzept. Das hat erstmal nix mit Qt zu tun.
Ich weiß schon aus anderen Threads, dass Eisflamme recht viel mit Qt arbeitet, deswegen habe ich das einfach reininterpretiert.
-
slot-machine (1):
Das denke ich nicht, Tim.Mechanics:
Ja, so habe ich das auch interpretiert und ist auf alle Fälle zu bedenken, danke.
MVC is nicht OK:
Stimmt, so ein Messagebus ist auch eine gute Variante. Wobei das bei mir vermutlich etwas zu übertrieben wäre, ich habe im Model nicht besonders viele Nachrichten, es gibt ein paar zentrale Objekte in allen möglichen Varianten, aber sonst passiert dort nicht viel. Single-User ist es in der aktuellen Ausgestaltung auch (noch). Aber das mit dem Bus merke ich mir auch, finde ich nicht dumm (so läuft ja ein normales Netzwerk ohnehin auch auf irgendeiner Schicht, da fliegt dann alles rum und man fischt sich, was man will - zumindest ungesichert, oder?).
-
Eisflamme schrieb:
Moment, M redet mit C?
Sorry. Das sollte C redet mit M heissen.
Das model kann notification systeme anbieten die der controller subscribed. Und der controller bietet diese dann weiter dem view an.
-
Genau, die Frage ist nur, ob man den Subscription-Teil auf Model-Ebene nicht weglässt, wenn man weiß, dass der Controller eh der Einzige ist, der darauf zugreift und somit selbst an den Stellen, wo er Änderungen ausführt, signals feuern kann.
Ich denke, ich werde es jetzt doch auf Model-Ebene einführen für meinen speziellen Fall. Grund ist einfach, dass es auch Use-Cases vom Backend gibt, für die sich Objekte gegenseitig untereinander subscriben. Die sah ich vorher nicht, aber dann hat sich das jetzt erstmal erledigt, danke.
Wenn jemand noch weitere Ideen hat, immer gerne, der Thread hat mir viel genützt!
-
Eisflamme schrieb:
Genau, die Frage ist nur, ob man den Subscription-Teil auf Model-Ebene nicht weglässt, wenn man weiß, dass der Controller eh der Einzige ist, der darauf zugreift und somit selbst an den Stellen, wo er Änderungen ausführt, signals feuern kann.
Ja wenn der Controller das weiss.
Nur weiss er das immer?
Hängt wohl von der Anwendung ab.Aber wenn der Controller es kann dann lieber im Controller als im Model. Aber nicht verrenken dabei.
-
Ich mach mich garantiert wieder unbeliebt hier, aber...
...sind wir jetzt nicht erst wieder bei "kommt drauf an" angekommen?Also bei der Feststellung dass man die Frage so allgemein einfach nicht sinnvoll beantworten kann?
Genau deswegen hab' ich auch ursprünglich darauf hingewiesen dass die Angaben zu schwammig sind. Und ja, ich hätte das ruhig freundlicher schreiben können, das seh' ich ja ein. Sorry dafür.
-
Mit dem Unterschied, dass einige sich wirklich darauf eingelassen haben, auch in etwas schwammiges mal etwas hineinzudenken und sich etwas Müzhe zu geben, wobei am Ende scheinbar trotzdem etwas fruchtbares herauskam.
Hier muss man oftmals sein ganzes Programm offenbaren, um bei einem Teilaspekt Hilfe erwarten zu dürfen (es sei denn, man schreibt wiederum zuviel, dann hat offenbar auch wieder niemand Lust das durchzulesen). Das widerstrebt manch einem vielleicht.
-
Shade of Mine:
Okay, danke.MVC ist nicht ok:
Hätte es nicht besser formulieren können.Die Gedanken vor dem "kommt drauf an" reichen mir. Da, wo das mit dem "kommt drauf an" anfängt, kann ich selbst weiterdenken. Bis dahin gibt es aber genug zu überlegen und das Defizit konnte ich gut verbessern durch den Thread. Die Details hätten nur gestört, abgelenkt und Antworten, die sich auf Details bezogen hätten, mir nichts genützt (auch weil ich das meistens selbst gut genug abschätzen kann). Kann daher nicht ausschließen, dass ich künftig wieder solche Threads poste, mir helfen die einfach...
Man könnte jetzt auch noch weiter aufdröseln in explicit knowledge und tacit knowledge, dass ich hier letztes suche und man so was aber nicht einfach 1:1 übertragen kann. Shade of Mines letzter Satz ist so ein Beispiel dafür, da steckt eine gewisse Erfahrung drin, die eine Präferenz angibt, gleichzeitig aber eine Bedingung dafür, dass man die auch versucht durchzusetzen. Klar ist das schwammig, aber irgendwann ist Softwaredesign eben auch intuitiv, man kann bei einer Softwarearchitektur vorher ja auch nicht alle Details im Voraus fürs ganze zukünftige Projekt wissen.
=> Hier muss man nach den Erfahrungen gehen, aber die sind nicht strikt, die geben nur gewisse Richtungen vor. Wenn ich mir anhöre, was andere da zu sagen haben, lerne ich aber mehr als wenn ich mir eine Detaillösung für ein Problem anhöre, das meins dann doch wieder nicht trifft
