Als controllers moeten delegeren, waar laat ik dan de 'niet-business-logic'?

In MVC (Model-View-Controller) moet is de controller de verbinding tussen Models en Views.

Models: representeren data en daarin zijn business rules geïmplementeerd
Views: de weergave
Controller: verbinding tussen views en models, delegeert zoveel als mogelijk

Maar in welke laag verstuur ik bv. een e-mail?

Weet jij het antwoord?

/2500

Een controller kan daar weer helper klassen voor instantieren. Die kun je dan klinkende namen als "MailProcessor" of "MailManager" geven. En goed nadenken over de lifetime en de scope van die instanties. Zijn ze bv. singleton en dus herbruikbaar, of hebben ze request scope.

Je antwoord zit al voor een deel in je vraag verwikkelt. De Controller delegeert en deze is dus ook degene die de aansturing zal doen. Ik weet niet of je in een specifiek Framework werkt maar ieder framework wat een beetje door ontwikkeld is, heeft hier zijn eigen ideologie over. In het kort komt het er op neer dat je lossen klassen net als tonb zegt en dat je deze op een of andere manier het werk laat doen. Een simpel concreet voorbeeldje is een Account klasse die een methode createNewAccount($data) heeft. In het simpelste geval instantieërt de controller deze nieuwe klasse en roept enkele deze createNewAccount($data) methode aan waarna er een resultaat uit komt. Dit resultaat zou dan weer terug kunnen komen bij de controller waarna je een specifieke redirect of een view render kan doen. Ik hoop dat het nu wat meer helder is voor je.

Stel zelf een vraag

Ben je op zoek naar het antwoord die ene vraag die je misschien al tijden achtervolgt?

/100