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

Reply via email to