text: factory class — Webstatt 2006 - 2012 Archiv
  Dustwolf am 14.08.07 20:43
  Auch auf die Gefahr hin, dass ich nerve... :D
  Ich hab mal nen bisschen weiter rumgespielt mit nem Framework und bin jetzt wirklich an dem Punkt angekommen, wo ich die einzelnen Objekte verbinden muss.
  [*]template system
  [*]db system
  [*]statistik
  [*]user functions
  Jedes dieser Objekte soll auf die anderen zugreifen können und im Idealfall soll jedes Objekt nur einmal angelegt werden... Also sollten die alle auf das richtige Objekte zugreifen und nicht einfach jeder nen neues für sich anlegen.
  Das sind aber erstmal nur die Standardfunktionen, hinzu kämen im Einzelfall natürlich noch Funktionen für die Seitengenerierung (also Newsarchiv, Forenübersicht, Statistikausgabe). Also die eigentliche Seite, denn der Rest sind nur Hilfsfunktionen (also quasi notwendige Funktionen, um die eigentlichen Methoden zu entlasten und das ganze dynamischer zu gestalten).
  Ich hoffe, soweit ist klar, worauf ich hinaus will. Denn hier im Forum bin ich noch nicht so wirklich weiter gekommen und Google liefert mir mit den Suchbegriffen php factory class tutorial und was es so alles gibt viele Archiveinträge und Mailinglisten, aber keine echten Erklärungen. Das sind meist nur konkrete Fragen und Antworten oder ähnliche aber doch andersartige Themen.
  Lange Rede, kurzer Sinn: Bringt mich so nicht weiter! :D
  Rebel4s am 14.08.07 22:36
  schau dir mal das singleton/registry pattern an, für seitenverwaltung ggf command pattern.
  mab am 15.08.07 22:44
  mhm. überleg dir erst wie du deine anwendung aufteilen möchtest. eine typische architektur besteht ja aus präsentation, businesslogik und der datenschicht. die unterschiedlichen komponenten musst du den schichten zu ordnen.
  template system => präsentation
  1) Command Contoler
  2) Template View und Helpers
  db system => datenschicht
  1) model (z.B. mit propel umwandeln)
  statistik kannst du vielleicht der businesslogik zuordnen. die lösung lautet wie sehr oft MVC. (gibt ja grad einen thread im forum)
  wenn du ein objektorientiertes konzept aufbauen möchtest, dann solltest du die user requests über einen controller an die schichten weiterleiten.
  naja, musst mal googln und viel lesen. weiß nicht ob das in etwa rüberkam.
  um nochmal näher auf deine frage einzugehen.
  wenn du verschiedene klassen und interfaces hast, dann kannst du ja einfach objekte erstellen und diese weitergeben.
  sagen wir der benutzer ruft dein newsarchiv auf.
  1.) datenbank objekt einbinden oder irgendwo her auslesen
  2.) template objekt erstellen und newsarchiv template parsen.
  je nach implementierung musst du halt schauen, dass die template instanz die entsprechenden werte erhält. z.B. davor alle daten in ein array stopfen und dann über einen asssoziativen schlüssel für das template verfügbar machen.
  Rebel4s am 15.08.07 22:55
  würdest du die sql befehle in eigene Klassen/Methoden kapseln oder es auch in die Businessschicht direkt schreiben, aber natürlich immernoch eine Db Klasse verwenden.
  Also wie kann man Model und Control trennen, da ja sql befehle auch eigentlich control sind oder?
  mab am 15.08.07 23:14
  mh kommt drauf an.. aber eher nicht. die businesslogik schicht beinhaltet konkrete klassen, mit denen ich irgendeinen geschäftsprozess abbilden kann, z.B. das berechnen von artikeln in einem online shop.
  user legt einen artikel in seinen warenkorb. das ist ja im grunde ein request. diese anfrage wird durch den controller (und viele andere patterns) verarbeitet. das heißt:
  1) controller ruft meine daten aus der datenschicht, sprich dem model ab. das gilt dann, wenn schon aritkel im warenkorb liegen und der berechnete preis z.B. in der datenbank gespeichert wurde. die rückgabe verarbeitet er weiter.....
  2) controller ruft ein business objekt auf. sagen wir es gibt eine klasse BerechneWarenkorb.php mit der methode kumulierePreise(). die rückgabe aus der datenschicht läuft hier direkt rein und wird dann verarbeitet. das ergebnis nimmt wieder der controller und leitet es an eine ViewKlasse weiter. am schluss ist das dann die ausgabe im browser
  Nummer 1) muss natürlich nicht so sein. sagen wir der user hatte nichts im warenkorb und legt einen neuen artikel rein. dann wird halt gleich die business class aufgerufen und der preis berechnet. sql hat in der klasse eigentlich nichts zu suchen.. es reicht wenn du mit ein und ausgabe arbeitest. ansonsten musst du irgendwann in der klasse rumfroschen, wenn du ne änderung vornehmen willst.
  das kannst du jetzt unglaublich weiterspinnen. schon alleine die artikel, die vom kunden während des surfens angeklickt werden, kannst du über den controller an die datenschicht weiterleiten und dort ablegen. beim nächsten besuch wird dann überprüft, was der besucher das letzte mal angeschaut hat......