On Tue, Feb 15, 2011 at 8:35 AM, Juliusz Gonera <[email protected]> wrote: > Mike Orr wrote: > >> In 2005 MVC for the web was still a shiny new idea. But in the >> following six years people used it and discovered its limitations and >> blogged about it. Namely, that MVC was designed for an environment >> very different from the web, it fits web applications imperfectly, and >> people sometimes agonize how to shoehorn their app into the >> formalities of MVC, which is counterproductive. Anybody who studies >> MVC will come across these complaints, and will see that the current >> generation of browsers is going "beyond MVC". That should reassure >> them that Pyramid isn't being substandard by doing this. > > Could you give an example of such case (where MV is better than MVC for a > web app)? Or a link to some blog post. I, by no means, want to start a flame > war or argue that what you stated is not true. I'm just unexperienced and > curious ;)
I've encountered it multiple times in my apps, and if you search the pylons-discuss archive you'll see the previous MVC controversies. I don't know of any particular blog article on it. MVC recommends a clear separation between your business logic (the model), the presentation format (the view), and the framework API (the controller). The view in this case is the HTML format and the form fields. A nested model object has to be flattened to be represented as form controls, and unflattened when the form is submitted. Other input (query parameters) have to be parsed using framework-specific APIs, so they should be parsed in the controller. The advantage of MVC is that you can plug in a different model implementation (say a different database type) or a different set of views (say a different template library) without affecting the other two parts. And you can theoretically port the application to a different framework by replacing just the controller part. MV keeps the model separate but merges the controller and view. There's a very good reason to keep your business logic framework-neutral so that it can be used in other contexts. But it becomes more trouble than it's worth to distinguish between the controller and the view. I can't give a specific example because it mainly happens in large, complex apps. One specific object that you're not sure if it's more of a "controller thing" or a "view thing". I said that the HTML format is always a "view thing", but sometimes it's easier to do in a loop in the controller. And sometimes the template needs to do a calculation that's arguably a "controller thing". And sometimes it's hard to tell whether something belongs in the model or controller too. Should the model have a database-neutral layer with a database-specific backend? Should I put *everything* SQLAlchemy-specific into the model even if it means writing a lot of small class methods, or making the methods complicated with arguments? Does it make it more or less readable to put that code in the model away from the code that uses it (which may be in the template)? It's so easy to pass a SQLAlchemy query to the controller and let it call .all() and .count(), and to pass it to the template and let it iterate the records. So why not do it? But then you've created a SQLAlchemy dependency in your actions and templates. With MV we keep the frustrations of dealing with a distinct model, but we eliminate the frustrations of dealing with a distinct view. In practice, many templates are so framework-specific anyway that they can't be directly used in another framework. In MV, the template is just an implementation detail of the view, and we don't worry about it otherwise. Another problem in Pylons is that there's no obvious place for view logic. Equating the view with the template means that any view logic (Python code) has to be embedded in the template or called from the template. But it's harder to debug Python code embedded in a template if an exception occurs. And if you have a large amount of code with loops or nested if's, it's easier to deal with in a proper Python module, which in Pylons' case means the controller. This can occur if you need to process all the records in a list before displaying them; e.g., to calculate additional display fields. But then, oops, you're putting view logic into the controller and that's bad. But it's not that bad, so people do it anyway. Another approach would be to have view functions which invoke their templates. That would provide a proper place for Pylons view code while still maintaining a separation between controller code and view code. But then every template would need a corresponding view functions, and you'd have to create a new subpackage for the view functions because Pylons doesn't have an existing place for them. And it means coordinating between three things together (the controller, view, and template) rather than just two (the controller and the template). With MV you can escape the dilemma entirely. -- Mike Orr <[email protected]> -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
