> -----Original Message----- > From: Perrin Harkins [mailto:[EMAIL PROTECTED]] > Sent: 13 June 2002 03:43 > To: Fran Fabrizio; [EMAIL PROTECTED] > Subject: Re: separating C from V in MVC
> > 2. Does the first part of my code above even remotely resemble a > > Controller? > > Sort of. It does choose a view and it does parse some user > input, but a > controller is more than just a dispatcher. It would include > some of the > code that you're currently putting into your doDoctorActivity() sub. > The idea is that the model objects represent just the data in your > application (the nouns) and the controller understands how to > translate > user input into a series of method calls on the model objects to carry > out the user's request. > > It's hard to give a good example that is short, but let's say you were > building an application to sell concert tickets. The act of > buying the > ticket might involve model objects representing a concert, a user, a > form of payment, etc. The concert object knows how to reserve a > specific seat (or call a seat object to do that). The payment object > knows how to verify and charge a credit card. The user object has a > mailing address. The controller knows how to turn the user's > form data > into a bunch of method calls on these objects that accomplish > reserving > the ticket and charging the user. If you find yourself writing a > "BuyTicket" module, that's a controller not a model object. > I disagree with this definition of a Controller. 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. In the same way that the View keeps the output format independent of the Model properties, the Controller keeps the User Input method independent of business logic. This is the reason for having a Controller class. Consider that your mod_perl website Controllers will have to understand all about web requests, headers, error headers, cookies, sessions, redirects, URLs and URL decoding etc etc - these are things that relate directly to how the user is interacting with the Model. 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. Consider the case where you wanted to buy hundreds or even thousands of tickets in a batch process - maybe you have agents that collect all the details for Kylie concerts, and then send them to you in a file. 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. You now have to maintain the business logic in two places. Always keep the _business_ behaviour in Models. The $Ticket->buy() processing must instantiate and create relationships to all the other objects it needs. Put all things that are specific to handling the User Interaction (eg web request) into your Controller. Business logic always goes into a Model. > The idea is that the model objects represent just the data in your > application (the nouns) and the controller understands how to > translate > user input into a series of method calls on the model objects to carry > out the user's request. Models are not just collections of stateful data, they are the right place to encapsulate complex business behaviour. At the risk of repetition, all behaviour [e.g. $Ticket->buy()] that is not specific to the User Interface should go into Models. Controller and View are closely related elements of GUI. This is like the old 'Two Tier App' problem... when business logic and GUI become inexorably entwined, maintenance goes out the window. Have a look at this picture: http://www.ddj.com/documents/s=867/ddj0105i/0105if2.htm which comes from this article: http://www.ddj.com/documents/s=867/ddj0105i/0105i.htm Maybe in the future, we will get drag-and-drop via the web - interpreting this should go into the Controller. Maybe in the future you will change the business requirements for buying Tickets - this will go in a Model, and the effect will be felt consistently in both your web applications and your batch processing. Regards Jeff
