PHP Sammelthread: Zend Framework und alles was dazugehört

ice-breaker · 21 Dezember 2009

äh ja, es ist eben so, dass per Default einfach erstmal alles verboten ist, nur wenn einem ein Recht eingeräumt wird, kann man dieser Tätigkeit nachgehen.

WhiZZler · 22 Dezember 2009

bevor ich jetzt so richtig loslege mit dem projekt habe noch zwei anliegen..

meine anwendung soll auf mehreren dbms laufen.. deswegen verzichte ich auf auto_increment (wie schick das ist merkt man erst, wenn man es nicht mehr nutzt

) ich habe bis jetzt noch keine anständige möglichkeit gefunden das mit Zend_Db zu simulieren.. unter MDB2 gibt es die möglichkeit mit nextId('tabelle') die nächste id für die gewünschte tabelle auszulesen.. im hintergrund wird die id aus ner tabelle gelesen, die nur die aktuell höchste id gespeichert hat.. bei Zend_Db habe ich jetzt nach längerem suchen nix in der richtung gefunden.. die möglichkeit mit $_sequence ist ja auch nur für wenige dbms anwendbar.. habe ich an der falschen stelle gesucht? ich bin ernsthaft am überlegen, ob ich MDB2 verwenden soll.. (nicht nur aus dem grund.. aber wenn man komplett auf Zend_Db setzt, dann sind die queries recht unverständlich für leute, die sich damit nicht auskennen..)

und zum anderen habe ich ein problem mit den pfaden.. im produktivsystem wird das ganze in einem unterordner liegen.. um die pfade vom root verzeichnis aus angeben zu können muss man also immer das base directory vom public ordner voranstellen.. hat das framework dafür schon eine lösung? oder muss ich selber eine konstante deklarieren? (habe nur APPLICATION_PATH gefunden und das is nicht das, was ich möchte..)

und wie kann man das in css oder javascript dateien lösen? also mit pfaden zu bildern und so? da kann ich die konstante dann ja nicht verwenden..

fragen über fragen.. danke im vorraus!
mfg
whizzler

strolch00 · 22 Dezember 2009

Dann versuche ich mal ein paar Antworten zu geben:

WhiZZler schrieb:
bevor ich jetzt so richtig loslege mit dem projekt habe noch zwei anliegen..

meine anwendung soll auf mehreren dbms laufen.. deswegen verzichte ich auf auto_increment (wie schick das ist merkt man erst, wenn man es nicht mehr nutzt ) ich habe bis jetzt noch keine anständige möglichkeit gefunden das mit Zend_Db zu simulieren.. unter MDB2 gibt es die möglichkeit mit nextId('tabelle') die nächste id für die gewünschte tabelle auszulesen.. im hintergrund wird die id aus ner tabelle gelesen, die nur die aktuell höchste id gespeichert hat.. bei Zend_Db habe ich jetzt nach längerem suchen nix in der richtung gefunden.. die möglichkeit mit $_sequence ist ja auch nur für wenige dbms anwendbar.. habe ich an der falschen stelle gesucht? ich bin ernsthaft am überlegen, ob ich MDB2 verwenden soll.. (nicht nur aus dem grund.. aber wenn man komplett auf Zend_Db setzt, dann sind die queries recht unverständlich für leute, die sich damit nicht auskennen..)

Also ich bin mir nicht sicher ob ich das richtig verstanden habe, es geht Dir darum einfach den nächsten Datansatz aus einer Tabelle zu bekommen und das möglichst DBMS unabhängig, also ohne auto_increment?

Hat Zend_Db bzw. Zend_Db_Select nicht für solche Sachen eine Methode die next() oder so änölich heist? Ice dürfte da mehr wissen.

und zum anderen habe ich ein problem mit den pfaden.. im produktivsystem wird das ganze in einem unterordner liegen.. um die pfade vom root verzeichnis aus angeben zu können muss man also immer das base directory vom public ordner voranstellen.. hat das framework dafür schon eine lösung? oder muss ich selber eine konstante deklarieren? (habe nur APPLICATION_PATH gefunden und das is nicht das, was ich möchte..)

Was möchtest Du denn dann? Ist das korrekt das dann development und produktiv umgebungen in verschiedenen Unterordnern liegen? Wenn ja liegt die "index.php" dann einfach einen Ebene hoher im Public? Soweit ich weiß passt Du doch dann in dem Fall die Konstante APPLICATION_PATH einfach an und änderst den include_path. Ein direkteres Beispiel wäre dann hilfreich.

und wie kann man das in css oder javascript dateien lösen? also mit pfaden zu bildern und so? ...

Also ich perönlich gebe immer absolute Pfade an mit / beginnend, was mir zwar derzeit reicht, allerdings in bestimmten Situationen zu Problemen führen kann.(siehe letztes Zitat von Dir)
Aber dafür gibt es ab ZF 1.9 (glaube ich) den Base Path View Helper den man zur Not vorranstellen kann. Und man könnte so einen eigenen View Helper schreiben der den automatisch immer mit hinzufügt.

ice-breaker · 22 Dezember 2009

strolch00 schrieb:
Hat Zend_Db bzw. Zend_Db_Select nicht für solche Sachen eine Methode die next() oder so änölich heist? Ice dürfte da mehr wissen.

auch wenn ich kein Fan davon bin: Zend_Db_Table hat eine AutoIncrenment-Abstraktion über alle unterstützenden RDBMS, denn solch eine Funktionalität hat jedes RDBMS, sie heissen meist nur anders und funktionieren ein klein wenig anders.
Aber auch die normalen Db-Funktionen ($db->lastInsertId()) unterstützen sequences, man muss als Parameter nur den Sequence-Namen angeben, Datenbanken die AutoIncrenment von Haus aus können, ignorieren den Sequence-Namen dann

Also ich würde schon auf Zend_Db statt Pear::MDB2 setzen.

strolch00 schrieb:
Also ich perönlich gebe immer absolute Pfade an mit / beginnend, was mir zwar derzeit reicht, allerdings in bestimmten Situationen zu Problemen führen kann.(siehe letztes Zitat von Dir)
Aber dafür gibt es ab ZF 1.9 (glaube ich) den Base Path View Helper den man zur Not vorranstellen kann. Und man könnte so einen eigenen View Helper schreiben der den automatisch immer mit hinzufügt.

Base-Path nutze ich immer, funktioniert perfekt

Man braucht auch nicht unbedingt das Plugin, einfach nur das Html-Element in den Kopf und fertig.

WhiZZler · 22 Dezember 2009

strolch00 schrieb:
Also ich bin mir nicht sicher ob ich das richtig verstanden habe, es geht Dir darum einfach den nächsten Datansatz aus einer Tabelle zu bekommen und das möglichst DBMS unabhängig, also ohne auto_increment?

Hat Zend_Db bzw. Zend_Db_Select nicht für solche Sachen eine Methode die next() oder so änölich heist? Ice dürfte da mehr wissen.

ne, darum geht es nicht. mir geht es erstmal nur um das hinzufügen der datensätze.. da bis auf mysql kein dbms auto_increment unterstützt brauche ich bevor ich den datensatz anlege die id des anzulegenden datensatzes.. MDB2 löst das wie bereits erwähnt über eine sequence tabelle..

strolch00 schrieb:
Was möchtest Du denn dann? Ist das korrekt das dann development und produktiv umgebungen in verschiedenen Unterordnern liegen? Wenn ja liegt die "index.php" dann einfach einen Ebene hoher im Public? Soweit ich weiß passt Du doch dann in dem Fall die Konstante APPLICATION_PATH einfach an und änderst den include_path. Ein direkteres Beispiel wäre dann hilfreich.

genau so ist es. ich gebe meine pfade auch immer absolut mit / beginnend an.. geht ja auch nicht anders wegen den URLs und mod_rewrite.. ich brauche die base url jetzt in einer variable, damit ich sie in den views vor jeden pfad stellen kann.. ich habe mittlerweile Zend_Controller_Front::getInstance()->getBaseUrl(); gefunden.. werde damit wohl ne konstante definieren, die ich dann in den views verwenden kann..

ice-breaker schrieb:
auch wenn ich kein Fan davon bin: Zend_Db_Table hat eine AutoIncrenment-Abstraktion über alle unterstützenden RDBMS, denn solch eine Funktionalität hat jedes RDBMS, sie heissen meist nur anders und funktionieren ein klein wenig anders.

wie funktioniert das dann konkret? bzw hast du mir nen link? ich werde aus der docu leider nid so ganz schlau..

ice-breaker schrieb:
Aber auch die normalen Db-Funktionen ($db->lastInsertId()) unterstützen sequences, man muss als Parameter nur den Sequence-Namen angeben, Datenbanken die AutoIncrenment von Haus aus können, ignorieren den Sequence-Namen dann

entweder ich stehe auf dem schlauch oder lastInsertId() bringt mir nix.. kommt mir auch so vor als verstünde ich nich so ganz, was sequence denn genau bedeutet.. ich mach mich da erstmal noch schlau

ice-breaker · 22 Dezember 2009

WhiZZler schrieb:
genau so ist es. ich gebe meine pfade auch immer absolut mit / beginnend an.. geht ja auch nicht anders wegen den URLs und mod_rewrite.. ich brauche die base url jetzt in einer variable, damit ich sie in den views vor jeden pfad stellen kann.. ich habe mittlerweile Zend_Controller_Front::getInstance()->getBaseUrl(); gefunden.. werde damit wohl ne konstante definieren, die ich dann in den views verwenden kann..

du brauchst es nicht immer davor stellen

Base-Tag

WhiZZler schrieb:
wie funktioniert das dann konkret? bzw hast du mir nen link? ich werde aus der docu leider nid so ganz schlau..

Sequences funzen in jedem RDBMS ein wenig anders, deswegen ist so eine Abstraktion wie Zend_Db ja sinnvoll.

WhiZZler schrieb:
entweder ich stehe auf dem schlauch oder lastInsertId() bringt mir nix.. kommt mir auch so vor als verstünde ich nich so ganz, was sequence denn genau bedeutet.. ich mach mich da erstmal noch schlau

15.1.4.2. Retrieving a Generated Value

Sebmaster · 22 Dezember 2009

WhiZZler schrieb:
wie funktioniert das dann konkret? bzw hast du mir nen link? ich werde aus der docu leider nid so ganz schlau..

PHP:

$db->insert(array());
$db->lastInsertId('table', 'column');

funktioniert bei allen DBMS. Die Sequenz (wenns diese in einem DBMS gibt, muss dann den namen table_column_seq haben (nach PostgreSQL-Convetions)).
MySQL und Konsorten ignorieren den Parameter und geben dir auto_increment zurück

ice-breaker · 22 Dezember 2009

ich mach dann mal nen kleinen Exkurs wie Sequences funktionieren, am Beispiel von Oracle

Es beginnt immer mit der Definition einer Sequenz, das ist einfach eine Art Variable die hochgezählt wird, ist natürlich aber persistent:

Code:

CREATE SEQUENCE userid_seq
START WITH 1
INCREMENT BY 1;

ich denke das ist ganz verständlich einfach die "Variable" userid_seq definieren mit einem Startwert von 1 und beim inkrementieren steigt es immer um eins.

Den nächsten Wert erhält man dann mittels:

Code:

userid_seq.nextval

Das RDBMS kümmert sich dann um das Synchronisieren und und und.

Dementsprechend einfach ist also das Einfügen eines Users:

Code:

INSERT INTO user (id, name, passwd) VALUES (userid_seq.nextval, 'whizzler', GNUHASH_SHA256('whizzler's pw'))

Also, soviel Magie ist das nicht, MySQL macht es einfach automatisch, bei anderen RDBMS muss man es manuell machen, hat dafür aber mehr Kontrolle, da es viele Config-Optionen für Sequences gibt.

WhiZZler · 23 Dezember 2009

versteh ich das richtig, dass ich mich eigentlich gar nicht um die fortlaufenden ids kümmern muss, wenn ich zend_db verwende? ich erstelle einfach ne klasse für jede tabelle mit einer definierten sequence.. diese sequence muss dann eben erstellt werden, wenn die tabellen für ein anderes dbms gedumpt werden.. aber darum kümmere ich mich dann erst später.. und so lange ich mit mysql arbeite reicht es das als $_primary gekennzeichnete feld mit auto_increment auszustatten..

schon sehr schick, das

und der base tag ist auch ne überaus schicke sache! hatte ich komischerweise noch nie von gehört

edit:
es ist mir wirklich schon fast peinlich, diese frage zu stellen.. aber ich bin jetzt schon seit ner knappen stunde am verzweifeln und habe keine lust mehr, noch mehr zeit zu verlieren..

ich will ein modul einbinden.. dafür benutze ich $front->addControllerDirectory('pfad/zum/modul/ordner/', 'modulname'); in _initModules() in der bootstrap

laut docu müsste das schon ausreichen, um über eine url im folgenden format ":module/:controller/:action/*" auf das modul zugreifen zu können..
wenn ich das versuche, dann bekomme ich aber immer eine fehlermeldung, dass der controller nicht vorhanden ist.. als modul bekomme ich jeweils "default".. es wird also nicht erkannt, dass ich eigentlich ein anderes modul haben möchte :/

ice-breaker · 23 Dezember 2009

ja das obere stimmt so weit, du brauchst aber nicht Zend_Db_Table, du kannst auch einfach die Zend_Db-Befehle nehmen.

füge nicht einen Controller mit der Modulinfo hinzu, sondern sag dem Zf einfach den Ordner in dem deine Module liegen

Ich weiß gerade nicht auswendig, wie die Methode heisst.

strolch00 · 23 Dezember 2009

PHP:

$front->addModuleDirectory('/path/to/application/modules');

Siehe hier

Oder einfach per application Resource mit

Code:

resources.frontController.moduleDirectory = APP_DIR "\module"
resources.frontController.defaultModule = "default"

WhiZZler · 26 Dezember 2009

hi! das mit dem modul hat mittlerweile geklappt.. ich hatte wohl irgendwas mit den pfaden falsch.. danke auf jeden fall nochmal

ich bin momentan dabei, eine anständige implementierung für die models zu erstellen und bin nicht so wirklich sicher, wie ich das ganze aufbauen soll..

wenn die daten direkt aus einer datenbank kommen, dann reicht es im prinzip ja schon die tabellen klassen, die Zend_Db_Table_Abstract erweitern und als models zu verwenden und in diesen klassen dann die gewünschten model spezifischen methoden zu schreiben.. aber irgendwie gefällt mir das nicht so recht, weil das zumindest nach meinem (wohl nach wie vor recht fehlerhaften

) verständnis nicht der sinn der sache ist..

in dem buch von stefan eggert zum zend framework habe ich einen ansatz gesehen, den ich ein wenig angepasst und erstmal umgesetzt habe.. 100% glücklich bin ich aber trotzdem noch nich..

ich habe ein interface für die models geschrieben.. in diesem interface werden einige methoden vorgeschrieben, die jedes model implementieren muss.. also zb fetchEntries(), fetchEntry($id) und solche 0815 operationen..

für jedes backend gibt es eine abstrakte klasse, die diese methoden implementiert.. (also einmal zb Model_Database_Abstract, Model_Soap_Abstract, usw..)

in einer vorangeschalteten abstrakten klasse, die für alle models gilt, wird das laden des storage objekts übernommen.. mit storage objekt ist zb bei einer datenbankanbindung ein objekt von einer klasse die Zend_Db_Table_Abstract erweitert gemeint..

in den konkreten models wird jetzt der klassenname des "storage objekts" als parameter definiert und dann werden eben noch weitere model spezifische methoden implementiert..
(ich hoffe ich konnte es für die, die das buch nicht gelesen habeneinigermaßen verständlich formulieren

)

mich stört an diesem ansatz, dass die models zunächst ja nur ein wrapper für die storage objekte sind.. die methoden, die die models von anfang an liefern könnten theoretisch auch direkt auf den storage objekten ausgeführt werden.. und dadurch, dass jedes model an genau ein storage objekt gebunden ist bräuchte ich in den meisten action controllern wohl mindestens 2 models, mehr wären wohl auch keine seltenheit..

mich würden einfach mal eure ansätze interessieren.. oder links zu dem thema.. (habe nix vernünftiges gefunden.. wusste wohl nicht, wonach ich suchen soll

) wie gesagt bin ich mit dem ansatz noch nicht 100% glücklich.. und um mir eigenständig nen guten ansatz auszudenken bin ich wohl nicht weit genug im oop sumpf drin

edit: haidernai! ist der text lang geworden. danke schonmal für jeden, der die geduld hat das ganze durchzulesen

ice-breaker · 26 Dezember 2009

WhiZZler schrieb:
edit: haidernai! ist der text lang geworden. danke schonmal für jeden, der die geduld hat das ganze durchzulesen

tut mir leid, ich hatte sie nicht, weiß aber worauf du hinaus willst :ugly:

Webcast: Play-doh: Towards Better Object Modeling
:arrow:

DAO-Implementierungsansatz von mir
:arrow:

DAO-Implementierungsansatz von akkie inkl. Service-Layer

Das war eine sehr spannende Diskussion im Zfforum über Models (auch wenn ich gelegentlich das Pattern verwechselt habe :biggrin:

) und halte ich persönlich richtig implementiert auch für die beste Lösung der Models (ist nicht ohne Grund auch der Standard in Java).
Eine perfekte Lösung habe ich dafür aber auch noch nicht gefunden, wie die angehängten Fragen in meiner Implementierung zeigen.

Durch die Kapselung des Datenzugriffs lässt sich bei guter Modellierung der Objekte im Nachhinein auch die gesammte DB umbauen oder auf andere Persistenzmedien setzen ohne dass der Code angefasst werden muss, der Layer zum Speichern muss natürlich angefasst werden, aber der Rest nicht.

Warnung: Die 3 Links sind starker Tobak, das Einlesen und Nachvollziehen wird einige Zeit in Anspruch nehmen.

Anmerkung: Was ich in den Threads genau geschrieben habe, weiß ich nicht mehr, in manchen Punkten habe ich mitlerweile meine Entscheidung möglicherweise geändert, aber meinen DAO-Ansatz (ohne Service-Layer) vertrete ich so noch immer, nur meine Auffassung zum ServiceLayer hat sich möglicherweise geändert.

Edit: Der Service-Layer-Ansatz von Akkie entspricht dem, wie ich nach momentanen Gutdünken auch den Service implementieren würde, nur würde ich dabei eben auf meine DAO.Implementierung zugreifen, wie sie in meinem Implementierungsansatz steht, der Vorteil dieses Service-Layers ist nämlich dass man ihn mittels Zend_Soap_Server oder Zend_XmlRpc intern als eigene API nutzen kann, wenn man dies möchte.

WhiZZler · 26 Dezember 2009

ice-breaker schrieb:
tut mir leid, ich hatte sie nicht, weiß aber worauf du hinaus willst

hehe

so lange du verstanden hast, worauf ich hinaus wollte ist alles bestens :biggrin:

werde mir den webcast heute abend mal anschauen.. und mir die threads dann danach zu gemüte führen..

WhiZZler · 28 Dezember 2009

doppelpost ahoi, aber sonst liest es ja niemand

ich habe mich jetzt mal ne zeit lang mit der thematik beschäftigt und bin denke ich zu einem ansatz gekommen, der für meine zwecke ausreichen sollte..

in den mappern werden die methoden bereitgestellt, die für ein jeweiliges model benötigt werden.. standardmäßig sind das update(), delete(), fetchAll() und konsorten.. der rest dann je nach bedarf.. die mapper kommunizieren dann mit dem dao und führen auf diesem (bzw mit dessen hilfe) die methoden aus (zum teil ist das im prinzip nur ein wrapper, interessant wird es dann erst bei den nicht 0815 operationen..) damit nicht in jedem mapper diese 0815 methoden implementiert werden müssen stehen diese in einer abstrakten klasse Models_Database_Abstract, Models_Soap_Abstract oder was auch immer..
damit die mapper für verschiedene datenquellen austauschbar sind werden sie gegen jeweils gegen ein interface programmiert.. also zb Models_UserMapper_Interface..

so kann man die datenquellen jederzeit austauschen.. der einzige dorn im auge ist, dass bei diesem einsatz eine feste dependcy zu den mappern besteht.. das ist aber denke ich verschmerzbar..

der aufbau ist relativ einfach und wohl auch nicht der beste.. für meine zwecke sollte es aber dennoch ausreichen denke ich.. es sei denn ich habe irgendwelche dinge ganz grob und fahrlässig übersehen

ice-breaker · 28 Dezember 2009

tut mir leid, ich kann mir das gerade echt nicht vorstellen, am besten untermauert man sowas immer mit sample-code

WhiZZler · 28 Dezember 2009

ice-breaker schrieb:
tut mir leid, ich kann mir das gerade echt nicht vorstellen, am besten untermauert man sowas immer mit sample-code

alles klar.. sorry

ich hatte bis jetzt nur das konzept und noch keinen code und dachte mir, ich vertraue meinen rhetorische fähigkeiten, aber die hab ich wohl mal wieder überschätzt

vorneweg.. ich habe mir für meinen ansatz von mehreren stellen inspirieren lassen.. hauptsächlich von den links von dir, dem quickstart und dem ansatz aus dem zend buch, den ich bereits umgesetzt hatte.. die namenskonventionen habe ich jetzt einfach mal ohne hintergedanken aus dem quickstart übernommen..

DAO:

PHP:

Class Default_Model_DBTable_User extends Zend_Db_Table_Abstract
{
  protected $_name = 'user';
  protected $_primary = 'user_id';
}

Mapper Interface (einfach die methoden, die ein UserMapper bereitstellen muss)

PHP:

class Default_Model_UserMapper_Interface
{
  public function find($id);
  public function fetchAll();
  public function setUserStatus($id, $status);
  // usw.. sind natürlich mehr methoden nötig
}

der konkrete mapper

PHP:

class Default_Model_UserMapper_Db implements Default_Model_UserMapper_Interface
{
  protected $_dao = null;
  protected $_daoClass = 'Default_Model_DBTable_User';

  public function __construct()
  {
    $this->_dao = new $_daoClass;
  }

  public function getDao()
  {
    if($this->_dao === null)
    {
      $this->_dao = new $_daoClass;
    }
    return $this->_dao;
  }

  public function setUserStatus()
  {
    //user status setzen
  }
  
  //die weiteren methoden, die das interface vorschreibt
}

wegen dem interface kann man jetzt relativ einfach auch andere datenquellen implementieren.. das dao objekt wird dann erst in dem mapper erstellt..

in dem eigentlich model, Default_Model_User steht dann die geschäftslogik.. also eingaben validieren, userrechte überprüfen usw..

PHP:

Class Default_Model_User
{
  $_mapper = null;
  public function __construct(Default_Model_UserMapper_Interface $mapper)
  {
    $this->_mapper = $mapper;
  }

  //hier kommen die benötigten methoden inkl geschäftslogik hin
}

im controller wird dann nur das model erzeugt und die benötigten methoden ausgeführt..

den teil zum vermeiden der reproduktion der 0815 methoden habe ich jetzt der einfachheit halber weggelassen.. ist im prinzip nur eine weitere abstrakte methode, in der diese methoden definiert werden.. diese klasse wird dann von den mappern erweitert..

wenn ich mir das so, wie ich es jetzt geschrieben habe anschaue, dann ist es dem ansatz, der in deinem dritten link stand doch schon sehr ähnlich

ice-breaker · 29 Dezember 2009

WhiZZler schrieb:
wenn ich mir das so, wie ich es jetzt geschrieben habe anschaue, dann ist es dem ansatz, der in deinem dritten link stand doch schon sehr ähnlich

gut ich bin sowieso kein Fan von akkie's Ansatz, dass weiß er aber auch, denn meiner Meinung nach ist die Kapselung des Models bei dem Ansatz nicht gegeben:
Dem Model-Objekt muss im Konstruktor ein Mapper übergeben werden, die Controller sollten aber gar nichts von einem Mapper wissen, sonst muss ich in allen Dateien wieder manuell den Mapper ändern. Ich habe die schöne Kapselung des DAOs verloren. Ich lasse mir einfach ein Objekt erstellen und kann dies befüllen/ändern und wieder speichern, was genau nun passiert und wie weiß ich nicht, wenn ich aber einem neuen User-Objekt erst einen Mapper übergeben muss, ist alles hinfällig.

PHP:

$user= new Default_Model_User(new Default_Model_UserMapper_Db());
$user->setUserStatus("regestriert"); // schau dir mal mein Beispiel an, da ist das über Konstanten gelöst ;) eine deutlich sichere Methode
$user->save();

oh, WhiZZler, wir wollen nun alles in Amazons SimpleDB speichern, korrigier doch mal alle User-Konstruktoren

WhiZZler · 29 Dezember 2009

ice-breaker schrieb:
speichern, was genau nun passiert und wie weiß ich nicht, wenn ich aber einem neuen User-Objekt erst einen Mapper übergeben muss, ist alles hinfällig.

oh, WhiZZler, wir wollen nun alles in Amazons SimpleDB speichern, korrigier doch mal alle User-Konstruktoren

jo.. genau das hatte ich ja auch als schwachpunkt des ansatzes genannt (in dem post ohne code beispiele

) 100% glücklich bin ich damit eigentlich auch nicht.. aber die wahrscheinlichkeit, dass in diesem projekt etwas anderes als ein dbms (von welchen durch zend_db ja schon genug abgedeckt sind) verwendet wird geht gegen null.. und falls doch der fall der fälle eintreten soll, dann gibt es immer noch die quick & dirty methode mit search & replace.. ist nicht schön, aber wie gesagt ist die wahrscheinlich sehr, sehr gering..

ein anderer, nicht besonders eleganter weg, um auch mit diesem ansatz für alle eventualitäten gerüstet zu sein wäre eine config file.. aber das ist wohl auch nicht das wahre..

mein größtes problem bin momentan ehrlich gesagt ich selbst.. mir brennt es unter den fingern und ich habe keine lust noch länger am konzept zu arbeiten.. deswegen bin ich gerade kurz davor die von mir gepostete 1b lösung umzusetzen

ich glaub ich schlaf am besten noch ne nach drüber und schau dann weiter..

ice-breaker · 29 Dezember 2009

schau dir mal die public API meines Entwurfes an, also die ist gewappnet gegen alles

Deine Mapper und alles baust du dann in der UserDaoImpl ein, UserImpl speichert nur die Attribute und gibt sie eben über das Interface wieder her.

Also über der API dafür habe ich wirklich lange gegrübelt bis es so war, das funzt, nur ich weiß bis heute noch keine optimale Lösung, wie ich den Mapper in der UserDaoImpl implementieren soll.

Edit: Die set-Methoden der DaoFactory solltest du irgendwo in der Initialisierung aufrufen, die Controller, Services usw sollen sich nur noch von der Factory das Dao holen.

PHP Sammelthread: Zend Framework und alles was dazugehört

return void

Chancentod²

redraft.de

return void

Chancentod²

return void

null != null

return void

Chancentod²

return void

redraft.de

Chancentod²

return void

Chancentod²

Chancentod²

return void

Chancentod²

return void

Chancentod²

return void