Signals einfach Mal anbieten oder nicht?
-
Hi,
eigentlich ne ganz platte Frage: Wenn ich im Backend so diverse Datenstrukturen schreibe und im Controller vom Frontend merke, dass ich eigentlich gerne darüber Bescheid wüsste, wenn sich darin was ändert (Observer/Signal like), sollte ich dann im Backend ein Signal, worauf man sich verbinden kann, anbieten, sodass jemand Änderungen in Erfahrung bringen kann?
Oder ist das Unsinn, weil ja erst ab Controller-Schicht diese Idee wichtig ist, sodass ich dort halt bei Änderungen ein Signal für andere Controller-Teile emittiere.
Frage also: Signal/Slot schon im Backend oder erst im Controller anbieten?
Normalerweise würde ich die Frage damit beantworten, ob es irgendwie natürlich ist so eine Funktionalität im Backend zu haben. Das fällt mir aber bei Signals schwer. Theoretisch wäre es ja für jeden Datentyp möglicherweise interessant über Änderungen informiert zu werden. Mit der Idee müsste aber jede Datenstruktur im Backend so eine Funktion bekommen, was klar übertrieben wäre.
Nach welchen Kriterien beantwortet ihr so eine Frage?
Danke und besten Gruß!
-
Oh, komm, ein bisschen schwammiger als Backend/Fontent/Controller geht's doch sicher noch!
-
Backend ist die Kernfunktionalität des Programms, die man auch benutzen kann, wenn man sich ne Konsolenanwendung schreibt.
Frontend ist ein Sammelbegriff für alles, was das UI angeht. Dazu gehören also wirklich sämtliche Anzeigeklassen als auch eben die Controller-Klassen. Controller-Klassen sind schon seit ungefähr 3.000 Jahren die Vermittler-Klassen zwischen Backend und dem, was angezeigt werden soll, die vermitteln einfach und kennen (sind abhängig von) sowohl das (dem) Backend als auch die (den) Anzeigeklassen.
Und mehr Details sind für die Frage nicht notwendig. Wenn es dazu keine klare Antwort bei der Menge an Eingabevariablen gibt, habe ich nach Kriterien gefragt. Wenn ihr keine Kriterien habt, dann... kann ich mir bei jemandem, der mit der Entwicklung von UI-Projekten zu tun hat, nicht vorstellen. Wäre ich erfahrener, hätte ich die. Zumindest ein bisschen denken in Schablonen und Abstraktionen dürfte doch wohl der Standard sein...
-
Ich rede jetzt mal von View und Modell statt von Frontend und Backend...
Also bei mir hält es sich mit diesem MVC-Schmu so, dass ich nie wirklich verstanden habe, was die Leute da nun eigentlich wollen. Je nachdem von wem man Artikel liest steht da einfach was ganz anderes drin, niemand spricht von der selben Sache.
Grundlegend ist klar dass man irgendwo ein Datenmodell rumliegen hat und irgendwo einen View darauf. Was dazwischen ist, hängt wohl irgendwie von der praktischen Umsetzbarkeit ab. Wenn der View mit einem Controller zusammenarbeitet, dann kann man wunderschön mehrere Datenmodelle auf den View adaptieren oder mehrere Views auf ein Datenmodell. Wie man das nun umsetzt, hängt, wie ich finde ganz stark von den Gegebenheiten ab.
Man liest halt immer nur von Beispielen, in denen kaum bis gar keine Interaktivität gegeben ist, in denen nur ein Controller gezeigt wird, Undo ist eine neuere Erfindung, Animierter Kram ist was für neumodische Kiddies...
Ich finde, das lässt sich außer nach einem groben pi-mal-Daumen Schema nicht allgemeingültig festlegen.Nun zu Deiner Frage: Stell Dir vor, mehrere Controller hängen auf einem Datenmodell. Wie würde jetzt Controller 1 mitbekommen dass Controller 2 etwas am Datenmodell verändert hat? Entweder die Controller sprechen sich autark untereinander ab (Nur woher weiß man, welche Controller wo dranhängen, eine eigene Registry dafür?), oder sie tun dies unter Mithilfe von Funktionalität im Modell. Ich tendiere stark dazu, dass letzteres einfacher umzusetzen ist, wobei der erstere Fall von multiplen lokalen Controllern die beispielsweise über eine Internetverbindung am Modell hängen wohl etwas performanter sein könnte.
-
Signals/Slots hört sich zu sehr nach Qt an. Hier wär erstmal überhaupt die Frage, ob du es überhaupt im Backend verwenden willst, oder ob du dein Backend möglichst frei von solchen Abhängigkeiten aufbaust und nur die GUI mit Qt machst. Ist nur eine Überlegung, wir haben im Backend auch Qt verwendet.
Ansosten hab ich mir die Frage auch schon öfter gestellt. Beim MVVM Pattern von Microsoft würde sowas eher ins ViewModel kommen und nicht ins Modell. Ich würde auch eher versuchen, es mit Signalen oder Observern im Modell nicht zu übertreiben. Ich hab mal zum Spass versucht, eine Textverarbeitungskomponente zu entwerfen (bin gescheitert) und hab mich da auch schon gefragt, wie ich irgendwo im Code mitbekomme, dass sich das Dokument geändert hat. Ich würde ja im Endeffekt lauter "Events" wie "Block hinzufügt", "Block verändert" oder ähnliches brauchen. Das gehört dann meines Erachtens doch nicht in die Dokumentenklasse.
Hier kommt natürlich der Einwand von "MVC is nicht OK" ins Spiel. Das Problem hatte ich nämlich auch mit meiner Dokumentenklasse. Ich würde vielleicht am ehesten dazu tendieren, dafür eine andere Zwischensicht anzubieten. Wenn jemand direkt mit dem Modell arbeiten kann und weiß, dass er der einzige ist, kann er das direkt und ohne Performanceinbußen oder Overheard machen. Wenn man weiß, dass man mehrere Controller braucht, benutzt man eine Zwischenschicht, die zwischen Controllern und dem Backend liegt.
Dann kanns natürlich noch Fälle geben, wo der Backend wirklich Events verschicken muss, da spricht dann natürlich auch nichts dagegen. Wenn der Backend von außen Daten bekommt, oder selber irgendwas abarbeitet und über das Ergebnis informieren will, kann man hier natürlich schon im Backend Events anbieten. Ich würds nur vermeiden, Events für etwas anzubieten, was von der Schicht drüber ausgelöst wird. In dem Fall sollen sich die drüberliegenden Schichten auch drum kümmern, wer wie über so etwas benachrichtigt wird.
-
Eisflamme schrieb:
Und mehr Details sind für die Frage nicht notwendig.
Wenn du meinst.
Eisflamme schrieb:
Wenn es dazu keine klare Antwort bei der Menge an Eingabevariablen gibt, habe ich nach Kriterien gefragt. Wenn ihr keine Kriterien habt, dann... kann ich mir bei jemandem, der mit der Entwicklung von UI-Projekten zu tun hat, nicht vorstellen.
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).
Mit anderen Worten: ob man sie braucht oder nicht.
Mit anderen Worten: kommt drauf an.
Ist das so schwer zu verstehen?Wäre ich erfahrener, hätte ich die. Zumindest ein bisschen denken in Schablonen und Abstraktionen dürfte doch wohl der Standard sein...
Wenn du meinst.
-
Achja...
Eisflamme schrieb:
Backend ist die Kernfunktionalität des Programms, die man auch benutzen kann, wenn man sich ne Konsolenanwendung schreibt.
Frontend ist ein Sammelbegriff für alles, was das UI angeht. Dazu gehören also wirklich sämtliche Anzeigeklassen als auch eben die Controller-Klassen. Controller-Klassen sind schon seit ungefähr 3.000 Jahren die Vermittler-Klassen zwischen Backend und dem, was angezeigt werden soll, die vermitteln einfach und kennen (sind abhängig von) sowohl das (dem) Backend als auch die (den) Anzeigeklassen.
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.
Auch was GUI Anwendungen angeht sind die Begriffe da nicht so klar definiert.
Und natürlich macht es einen Unterschied welches "GUI Modell" man verwendet. MVC ist viel zu schwammig definiert um sinnvoll allgemein bzw. abstrakt darüber sprechen zu können.
-
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.
und @mechanis: signal/slot ist ein Konzept. Das hat erstmal nix mit Qt zu tun.
-
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
