Hallo Chris,
danke für das ausführliche statement. Ich denke mal, so ganz daneben lag
ich bisher nicht. Das Model ist für mich bisher tatsächlich nur ein Ort,
an dem die Eigenschaften eines "Objekts" erfasst und mit getter und
setter-Methoden abrufbar sind. Den Ansatz mit den Utility Classes werde
ich im Hinterkopf behalten, da meine Controllermethoden manchmal doch
umfangreicher werden.
Bei deinem Beispiel zur Methode "getPriceWithTax" wäre ich
wahrscheinlich wieder Richtung Controller geschwenkt. Aber das ist wohl
genau der Knackpunkt, gehört es noch zum Model oder nicht. Wo zieht man
die Grenze.
Ich vermute mal, das oft in der Literatur zitierte "Der Controller
koordiniert nur, das Model bildet die komplette Geschäftslogik ab" tut
ein weiteres, das hinter dem Model viel mehr vermutet wird und der
Controller nur eine Art Gehilfe darstellen könnte.
Viele Grüße
Eddy
Am 10.09.2013 19:27, schrieb chris Wolff:
Hi Eddy,
Ein Model, ist ein Datenspeicher.
es enthält eine Eigenschaften und die nötigen validationen dazu!
eventuell auch einfache funktionen die sich z.b direkt aus den daten
einens models ergeben.
ein model hat in der regel keine weitere logik ausser getter und setter.
eventuelle einfache berechnungs funktionen.
angenommen du hast eien artikel im shop.
könnte das model
z.b folgende werte Eigenschaften haben
price
Tax
dann könnte da model folgende zusätzlich eine funktion enthalten die
getPriceWithTax() heist um den preis mit der steuer zu ermitteln.
aber mehr funktionalität sollte eigendlich nicht im moddel abgebildet werden.
der Controller sollte den Datenfluss steuern.
er code des Controllers sollte immer überschaubar sein.
eine Action sollte nicht allzu lang werden.
wenn du komplexe logik abilden must ist es sinvoll dafür eine eigene
Utility Classe zu schreiben.
angenommen du must am ende deines formulars ein PDF generieren.
dann kannst due den gesamten code dafür natürlich im Controlle abbilden
aber schönwer währe eine lösung die einen pdfGenerator Classe
injected und dann diese nutzt.
z.b so (pseudo code):
function injectPdfGenerator($pdfGenerator){
$this->pdfGenerator = $pdfGenerator;
}
function newPdfAction($customerData){
$this->pdfGenerator->createPdfFromCustomerData($customerData);
$this->emailService->addAttachment($this->pdfGenerator->getPdfFilename());
$this->emailService->send();
}
hier ist die newPdfAction übersichtlich mann kann den informations
fluss gut verfolgen
die auffwendigen sachen passieren dann im pdfGenerator bzw. emailService
pdfGenerator und email service sind dann hoffentlich wieder klassen
die sich gut durch unit test testen lassen.
unit testing von controller logik ist etwas tricky
gruss chris
Am 10. September 2013 16:39 schrieb Eddy Wolbert <mailingl...@23zebras.de>:
Hallo Typo3-Gemeinde,
ich beschäftige mich jetzt schon einige Zeit mit extbase/fluid und auch
Domain Driven Design sowie das MVC-Paradigma ist mir einleuchtend.
Was mich aber immer wieder umtreibt ist die Frage, ob ein Sachverhalt
korrekterweise nun im Controller oder Model "abgehandelt" werden soll. Habe
ich z.B. ein Formular, so bastle ich mir jeweils dazu ein Model und lasse
hier die einzelnen Felder validieren. Weitere Verarbeitungen lasse ich dann
vom Controller vornehmen.
Ich muss gestehen, i.d.R. ist bei mir in den meisten Fällen der Controller
am arbeiten.
Gibt es evtl. Richtlinien, Handlungsanweisungen oder auch einfach
Erfahrungswerte, nach denen eindeutig die Verwendung von Model oder
Controller zu bevorzugen ist?
Ich tue mich da etwas schwer.
Vielleicht kann mir dazu ja jemand etwas sagen.
Vielen Dank
Eddy
_______________________________________________
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
_______________________________________________
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
