Jeff AA wrote: > I disagree with this definition of a Controller. I knew someone would.
> A Controller is > primarily responsible for mapping user input onto a business Model, and > should not know that buying a ticket requires creation of concert, > payment, seat, client, theatre, agent, reservation, whatever objects. Something has to know that stuff. You can call that something a controller, or you can make it a separate module and call it an "action" (like an EJB session bean in Java). Calling it part of the controller is an easy way to think about it for people raised on CGI, but does not fit exactly with some of the descriptions of MVC you'll find out there. Calling these actions part of the model is fine too. I don't think it matters in most cases, but if your actions (and not just your data objects) really do need to be used in the context of multiple UIs then you might want this extra step. > In the concert example, the Controller would interpret the web request, > create a Ticket object, and call $Ticket->buy( > %all_the_cleaned_up_params ). It would then pass this to the View to > render. That's it. No, I don't agree about that. It doesn't make sense for a ticket to understand how to buy itself. It should understand how to reserve itself, but knowing things like how to process a payment and when to e-mail the buyer a receipt have nothing to do with a ticket. You could make an action class called TicketAgent which would have a buy_ticket() method that operates on tickets, payments, and uers to accomplish the action of buying a ticket. I would usually just stick that in the controller, but you could separate it if you prefer. > If you had made the mistake of creating a web Controller aka BuyTicket() > module that understood it had to create concert, payment, seat, client, > theatre, agent, reservation, whatever objects, you would have to > duplicate all this logic AGAIN in the batch process Controller. No, the data objects are the same in either case but the BuyTicket part is very different. You make a new controller (or action) that accepts input and then loads up a whole list of Ticket objects and operates on them. There's usually not a lot of code here, since the details of how a ticket reserves itself are all hidden in the Ticket object and the details of how a payment gets processed are all hidden inside an Order object. If you do find yourself duplicating code between actions, you have the full power of OO programming at your disposal to fix that. A better argument for action objects would be if you have an e-mail interface to your system that lets people buy a ticket, exactly like they do through the web interface. Then you would want to reuse the code that operates on the data objects to buy a ticket, so you could package that up as a module. > Models are not just collections of stateful data, they are the right > place to encapsulate complex business behaviour. Okay, you convinced me. Next time I build a big system I'll try putting that stuff into action objects. It's probably overkill for small web projects though. Incidentally, PageKit is probably the closest to the notion of MVC you're talking about here. It doesn't offer any specific help with modelling your data as objects, but it follows the structure you describe pretty closely and you could use any data modelling module you like with it. - Perrin
