nicht angemeldet
Datenkopplung zwischen View und Model (MVP)
Robert R.
Datenkopplung zwischen View und Model (MVP)
Robert R.
Liebe Mitdenker,
liebe Wissende,
liebe Neugierige,
ja!
hat sich hier schon mal jemand _intensiver_ mit der Theorie der Datenkopplung (Model-View-Presenter) beschäftigt? Ich hätte nämlich gerne ein paar Tipps über gute, leicht verständliche Literatur.
Bisher habe ich nur in der Wikipedia etwas brauchbares gefunden - leider zu wenig Input.
Spirituelle Grüße
Euer Robert
--
Möge der Forumsgeist wiederbelebt werden!
Möge der Forumsgeist wiederbelebt werden!
-
Moin
hat sich hier schon mal jemand _intensiver_ mit der Theorie der Datenkopplung (Model-View-Presenter) beschäftigt? Ich hätte nämlich gerne ein paar Tipps über gute, leicht verständliche Literatur.
Hier ists ganz verständlich: http://www.infragistics.com/community/blogs/todd_snyder/archive/2007/10/17/mvc-or-mvp-pattern-whats-the-difference.aspx
Gruß Bobby
--
-> Für jedes Problem gibt es eine Lösung, die einfach, sauber und falsch ist! <-
### Henry L. Mencken ###
-> Nicht das Problem macht die Schwierigkeiten, sondern unsere Sichtweise! <-
### Viktor Frankl ###
ie:{ br:> fl:{ va:} ls:< fo:) rl:( n4:( de:> ss:) ch:? js:( mo:} sh:) zu:)-
Liebe Mitdenker,
liebe Wissende,
liebe Neugierige,ja!
hat sich hier schon mal jemand _intensiver_ mit der Theorie der Datenkopplung (Model-View-Presenter) beschäftigt? Ich hätte nämlich gerne ein paar Tipps über gute, leicht verständliche Literatur.
Hier ists ganz verständlich: http://www.infragistics.com/community/blogs/todd_snyder/archive/2007/10/17/mvc-or-mvp-pattern-whats-the-difference.aspx
Ok, schon mal ein Anfang.
Ich werde mal sammeln und mich damit beschäftigen, wenn ich mehr Input habe.
Die ersten Zettel sind zwar schon voll, aber da ist noch keine Struktur drin.Spirituelle Grüße
Euer Robert--
Möge der Forumsgeist wiederbelebt werden! -
Moin
hat sich hier schon mal jemand _intensiver_ mit der Theorie der Datenkopplung (Model-View-Presenter) beschäftigt? Ich hätte nämlich gerne ein paar Tipps über gute, leicht verständliche Literatur.
Hier ists ganz verständlich: http://www.infragistics.com/community/blogs/todd_snyder/archive/2007/10/17/mvc-or-mvp-pattern-whats-the-difference.aspx
Der Begriff Unit-Test ist mir in dem Zusammenhang unverständlich. Ich verstehe unter einem Unit-Test im Bereich der Webentwicklung zum Beispiel einen Test, ob ein Login in einen bestimmten Realm erfolgreich ist, wobei dazu ein Request auf eine bestimmte Webressource (URL) mit den notwendigen Credentitials (Benutzername, Passwort) erfolgt. Die Response liefert mir in jedem Fall bereits in den Headern die Informationen X-Realm: "Realm" und X-Login: "Benutzername", so dass ich das auch in automatisierten Tests vergleichen kann.
Eine Zugangskontrolle ist bei mir einzig und allein über die Konfiguration geregelt und somit vom Code der an den URL gebundenen Klasse (Modul) komplett getrennt.
Oder habe ich da was falsch verstanden?
-
Tach!
Ich verstehe unter einem Unit-Test im Bereich der Webentwicklung zum Beispiel einen Test, ob ein Login in einen bestimmten Realm erfolgreich ist, wobei dazu ein Request auf eine bestimmte Webressource (URL) mit den notwendigen Credentitials (Benutzername, Passwort) erfolgt.
Das sollte nicht Ziel des Unit-Tests sein. Der Test testet, ob dein Code korrekt arbeitet. Wenn du nun den Webserver oder auch eine Datenbank befragen musst, kann der Test fehlschlagen, obwohl dein Code gar keine Schuld hat. Zum Testen ob der Webserver oder die Datenbank arbeitet gibt es Monitoring-Systeme.
dedlfix.
-
Tach!
Ich verstehe unter einem Unit-Test im Bereich der Webentwicklung zum Beispiel einen Test, ob ein Login in einen bestimmten Realm erfolgreich ist, wobei dazu ein Request auf eine bestimmte Webressource (URL) mit den notwendigen Credentitials (Benutzername, Passwort) erfolgt.
Das sollte nicht Ziel des Unit-Tests sein. Der Test testet, ob dein Code korrekt arbeitet.
Also Code == Unit, ein Unit-Test testet nur den Code?
Schöne Grüße.
-
Tach!
Also Code == Unit, ein Unit-Test testet nur den Code?
Units sind (kleine) Einheiten deines Codes. Alles, was nicht klassenintern ist, wird getestet, und das auf positive und negative Ergebnisse. Wenn die Klasse mit anderen zusammenarbeitet, wird statt denen eine Attrappe (Mock) übergeben. Damit kann man einserseits prüfen, dass deine Klasse die richtigen Daten rausgibt und andererseits wie sie beim Erhalt bestimmter Daten reagiert.
dedlfix.
-
Tach!
Also Code == Unit, ein Unit-Test testet nur den Code?
Units sind (kleine) Einheiten deines Codes. Alles, was nicht klassenintern ist, wird getestet, und das auf positive und negative Ergebnisse. Wenn die Klasse mit anderen zusammenarbeitet, wird statt denen eine Attrappe (Mock) übergeben. Damit kann man einserseits prüfen, dass deine Klasse die richtigen Daten rausgibt und andererseits wie sie beim Erhalt bestimmter Daten reagiert.
Danke für die Info! Auf jeden Fall ist ein Unit-Test etwas mehr als nur zu prüfen, ob der Code kompiliert (das macht ja schon die IDE).
Für meine Fabrikmethoden könnte ich z.B. solche Unit-Tests automatisieren: Diese Methoden sind in kleinen Dateien (Perl-Packages in @INC/factory/) definiert und werden im Regelbetrieb über Instanzen verschiedener Klassen aufgerufen. Somit kann die aufrufende Instanz auch eine Instanz der Klasse 'Mock' sein (der Name gefällt mir, so hieß der Kater meines Nachbarn).
Als Beispiel liefert die Fabrikmethode main->configini('/path/file.ini') eine Hash-Referenz, im Fehlerfall undef. Eine andere Methode kriegt den Namen einer Datenbank, den Namen einer Tabelle und liefert 0E0 (true) oder undef, je nachdem.
Bevor ich das angehe in die Praxis umzusetzen: Habe ich das nun richtig verstanden?
Schöne Grüße.
PS: In Perl heißt das Aufrufen einer Methode über eine Instanz, dass die Instanz an die Methode übergeben wird.
-
Tach!
Auf jeden Fall ist ein Unit-Test etwas mehr als nur zu prüfen, ob der Code kompiliert (das macht ja schon die IDE).
Er ist dazu da, um zu prüfen, ob der Code das macht was er soll und das unterlässt, was er nicht soll. Er ist im besten Fall eine komplette Funktionalitätsprüfung.
Für meine Fabrikmethoden könnte ich z.B. solche Unit-Tests automatisieren: Diese Methoden sind in kleinen Dateien (Perl-Packages in @INC/factory/) definiert und werden im Regelbetrieb über Instanzen verschiedener Klassen aufgerufen. Somit kann die aufrufende Instanz auch eine Instanz der Klasse 'Mock' sein.
Mit Perl beschäftige ich mich nicht. Ich kann dir nicht sagen, ob das so im Sinne der Erfinder ist oder nicht. Ich nehme aber nicht an, dass sich die Perler darum noch keine Gedanken gemacht haben und dass dazu keinerlei Anleitungen zum Vorgehen existieren. Üblicherweise gibt es eine Mock-Klasse, der man den Namen eines Interfaces übergibt, und die daraus ein Objekt erstellt, über das man mit der zu testenden Klasse Daten austauschen kann. Da formuliert man zum Beispiel in Code: "wenn das Testobjekt eine bestimmte Methode aufruft, dann gibt als Ergebnis einen bestimmten Wert zurück".
Habe ich das nun richtig verstanden?
Kann ich dir nicht sagen, weil ich das anhand deiner Ausführungen anhand von Perl nicht beurteilen kann.
dedlfix.
-
hi,
Habe ich das nun richtig verstanden?
Kann ich dir nicht sagen, weil ich das anhand deiner Ausführungen anhand von Perl nicht beurteilen kann.
Ich habe inzwischen ein bischen weiter gelesen. Die Methoden meiner Factory kann ich fast alle mocken. Nicht zu mocken sind ein paar wenige Methoden, die von der aufrufenden Instanz abhängig sind, aber dass lässt sich leicht ändern (hatte ich sowieso irgendwann mal vor).
Einer Automatisierung kommt entgegen, dass alle meine Factory-Methoden im Erfolgsfall entweder eine statische Instanz (*) zurückgeben oder ein Scalar (was auch eine Referenz sein kann) und im Fehlerfall eine Exception (mit Backtrace) werfen, wobei der Return-Value undef ist.
*) Referenzen auf komplexe Datenstrukturen, die im Hauptspeicher gecached werden. Im Betrieb mod_perl oder mod_fastcgi ein beträchtlicher Performanze-Gewinn
Am Ende ist alles ganz einfach, aber hinterher ist jeder schlauer ;)
-
-
-
-
-
-
-
-
Moin,
einem Neueinsteiger würde ich leider ein Framework empfehlen. Leider, da ich kein Freund von Frameworks bin.
Doch anhand von den üblichen verdächtigen Frameworks (sprich den großen) sieht man sehr schnell wie ein MVC aufgebaut ist. Wenn man sich dann noch ein wenig in das Thema Software Patterns vertieft hat man relativ schnell und einfach Werkzeuge an der Hand um wirklich gut und effektiv arbeit zu können.Gruß
MwT - Most wanted T-Rex