Signals einfach Mal anbieten oder nicht?
-
Hi,
ui, danke für den ganzen Input, jetzt hab ich was zu lesen.
MVC ist nicht ok:
Also wenn ich zwei Controller habe, die miteinander kommunizieren sollen, würde ich einfach noch einen "Über"-Controller oder so was drüberbauen. Oder irgendeine Vermittlerschicht. Das ist für mich noch kein soo kräftiges Argument, aber ist sicherlich zu beachten, danke!Mechanics:
Also im Backend will ich QT (auf Dauer) auch raushaben. Signals/Slots dort würde ich halt mit Boost realisieren. Ich weiß nicht, ob man die Slot-Seite auch Slot da nennt, das habe ich wohl von QT abgeschaut.Ansonsten super Antwort mit vielen guten Idden und Anregungen wie so oft, danke.
hustbaer:
Das ist deine, sehr spezialisierte, Definition von Backend <-> Frontend.
Wenn du mit einem Entwickler sprichst der vorwiegend Compiler entwickelt, dann wird der vermutlich ne ganz andere Vorstellung haben.Okay, das erkenne ich an. Ich hoffe, es wurde in meiner Erläuterung klarer, was ich damit meine und das liefere ich dann ab sofort mit.
Wenn du meinst.
Tut mir Leid, dass ich das so sage, aber: Nachdem ständig solche herablassenden, unnötigen Aussagen von Dir kommen, glaube ich so langsam, dass Du auf solche Threads einfach nicht mehr antworten solltest, weil Du kaum bis keinen positiven Mehrwert schaffst und sich deine Beiträge immer weiter auf schnippische Aussagen reduzieren.
Mechanics Antwort war ein perfektes Beispiel dafür, dass die Informationen komplett ausreichend sind. Wie kommt es, dass der mir fast immer eine Antwort liefert, mit der ich perfekt arbeiten kann und die exakt meine Frage beantwortet und andere mehr Details brauchen? Letztes führt dann meist zu irgendeiner Detailantwort, die mir überhaupt nicht hilft, weil sie nichts mehr mit meinem Ausgangsproblem zu tun hat. Mit den Details direkt aus dem Projekt kann keiner was anfangen und ich kann die Antworten nicht übertragen (etwa auf neue Projekte, Teile des Projekts), weil sie zu (unnötig) detailverliebt sind => Daher abstrahiere ich.
Na gut. Kriterium dafür ob man im Model schon "changed" Events anbieten sollte ist, ob es Änderungen im Model geben kann die das ViewModel/der Controller/... sonst nicht mitbekommt (aber mitbekommen sollte/muss).
Schau, das ist schon etwas ganz anderes als das, was von den anderen Beiträgen kam. Selbst wenn das von außen jemand mitbekommen kann, weil er das volle Wissen über die Möglichkeiten der Änderungen hat, könnte es Sinn ergeben es auf Model-Schicht einzubauen.
Und schon haben wir einen Punkt, den wir auch auf diesem Level diskutieren können. Ist das so schwer zu verstehen?
Und hier:
Mechanics schrieb:
Ansosten hab ich mir die Frage auch schon öfter gestellt.
hustbaer: Aber ich darf die nicht hier im Forum stellen?
Mal ganz darüber hinaus finde ich Deine herablassende Art nicht wirklich konstruktiv und unangebracht ohnehin. Dann öffne meine Threads eben nicht mehr.
Klar kann das Model ein notification System anbieten. Die Idee von MVC ist ja, dass M mit C redet und C mit V und kein M mit V.
Daraus ergibt sich alles andere.
Moment, M redet mit C? Dann kann man ja ohne Änderungen gar nicht mehr M austauschen. Bei mir redet M mit keinem, daher könnte man auch einfach alles nutzen, ohne etwas zu ändern. Wenn M C kennt, hat man ja irgendwie eine Abhängigkeit, die zumindest ich gerade vermeiden möchte.
-
eisflamme ist doch der eine wo c++ wie java proggt
-
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
