Ayende @ Rahien

Dmitriy Nagirnyak commented on Do not put presentation concerns in the controllers!

Wed, 07 Jan 2009 00:08:39 GMT

Yep... Oren, Can you think about situations where it would be acceptable to do some sorting on the view?

Ayende Rahien commented on Do not put presentation concerns in the controllers!

Tue, 06 Jan 2009 11:07:16 GMT

Dimitriy, If I find anyone doing something like that on the view, I am going to hit them on the head with a clue stick. There will be bad things, we have to deal with that with code reviews, mentoring, etc.

Dmitriy Nagirnyak commented on Do not put presentation concerns in the controllers!

Tue, 06 Jan 2009 10:38:36 GMT

Sorry. It should be: <% var products = ViewData.AsEnumerable p.Name); %> >

Dmitriy Nagirnyak commented on Do not put presentation concerns in the controllers!

Tue, 06 Jan 2009 10:37:34 GMT

Upps. My ugly code has been stripped. Trying again. <% var products = ViewData.AsEnumerable >

Dmitriy Nagirnyak commented on Do not put presentation concerns in the controllers!

Tue, 06 Jan 2009 10:35:14 GMT

Ok. That's the key: " making the view talk to the controller for the action". But it is so huge attraction to write code like the one below instead of introducing additional layers. and there's no way to prohibit doing it so sometimes I can find such kind of code after myself :( It just works. Yes. But I don't sleep well with it and hope 10 seconds I spent for writing OrderBy won't become 10 days of debugging later.

Ayende Rahien commented on Do not put presentation concerns in the controllers!

Tue, 06 Jan 2009 10:16:28 GMT

View Model is my favorite, to tell you the truth. For web app, I would define some Json web services that you can use. Basically, it would all go into the same notion of making the view talk to the controller for the action

Dmitriy Nagirnyak commented on Do not put presentation concerns in the controllers!

Tue, 06 Jan 2009 10:11:38 GMT

Ok. Would you mind to give a quick sample of such interface? Should we use DTOs (or view models) instead of Business Objects? How would you compromise between flexibility and being protective, design practices guided?

Ayende Rahien commented on Do not put presentation concerns in the controllers!

Tue, 06 Jan 2009 10:01:32 GMT

Dmitriy, At that point you need to negotiate how to do things. Usually you build some sort of an interface that you use.

Dmitriy Nagirnyak commented on Do not put presentation concerns in the controllers!

Tue, 06 Jan 2009 09:59:29 GMT

Yes. I agree. Just curious how would you deal if the designer (a person who develops views only) would like to have some control over things that controller is responsible for (ordering, displaying some hierarchical data with lazzy loading when controller did not loaded the data etc)?

Ayende Rahien commented on Do not put presentation concerns in the controllers!

Mon, 05 Jan 2009 05:23:26 GMT

Dmitriy, The controller is responsible for that. Ordering should happen in the DB, not in the view.

Dmitriy Nagirnyak commented on Do not put presentation concerns in the controllers!

Mon, 05 Jan 2009 01:24:37 GMT

A quick question: Who (Controller or View) should be responsible for ordering Products displayed on the page? It seems that Controller should do it because of it requires some manipulations over the collection. On the other side a page designer might want to order products the way he/she wants, thus View is responsible for giving the order. Cheers.

Haacked commented on Do not put presentation concerns in the controllers!

Fri, 02 Jan 2009 20:44:06 GMT

Whoops. I meant the default content of the placeholder is ViewData["Title"] but anyone who defines that content in their specific view will override that.

Haacked commented on Do not put presentation concerns in the controllers!

Fri, 02 Jan 2009 20:42:47 GMT

We're making a change to Site.master in the default template to include a content section for the head section along the lines of what Ayende describes. By default, its default content will still display <%= ViewData["Title"] %>, but any given view can simply override it.

João P. Bragança commented on Do not put presentation concerns in the controllers!

Fri, 02 Jan 2009 16:23:29 GMT

What if you want to reuse the same set of controllers for a different set of views, as in a multi-tenant app? Unless you are working with a set of administration screens, your HTML views will need to be search engine optimized. This is often outsourced to 3rd parties. Are you going to give them the right to modify your controller code? Are you going to make the controller responsible for meta tags too? Speaking from personal experience, I've done this already and it was a mistake. What if the views weren't even HTML? If you wanted to use your controllers in a desktop app, and you had WPF as your view engine, you are now making you controller do extra work for stuff the view won't need.

Thomas Eyde commented on Do not put presentation concerns in the controllers!

Fri, 02 Jan 2009 10:45:27 GMT

"Another option, which is more friendly to designers, it to use a presentation model. Which take care of this. Presentation model is again, 100% view logic." Now I am lost. In order to make a presentation model available for the designer to use, it has to be created somewhere. And since the presentation model was suggested as a better approach than helpers, aren't we left with the controller as the best place? The quality of an implementation should be based on how we do it, not what we call it. However, the I feel the latter is what we are doing here.

Peter Morris commented on Do not put presentation concerns in the controllers!

Wed, 31 Dec 2008 18:14:15 GMT

In a task oriented system the same view may be used for many purposes, especially when selecting a value from a short list. In this case you would want the view to display either "Select a day of the week to continue" or "Select a site to visit" Just because there is no useful reason for the example doesn't mean the approach has no use. Sure the example is commercially pointless, but it's not completely pointless because its point is to show how you can set *something* in the controller and have it displayed in whatever way the view decides is appropriate.

Ayende Rahien commented on Do not put presentation concerns in the controllers!

Wed, 31 Dec 2008 15:52:30 GMT

> You can have anything in your helpers. They can erase your hard drive etc. No, you can't. If your helpers do things that are not directly related to presentation, that is an issue. I don't believe is putting developers in a straight jacket just to "protect" them.

bungle commented on Do not put presentation concerns in the controllers!

Wed, 31 Dec 2008 12:04:06 GMT

"Helpers are 100% part of the view logic." You can have anything in your helpers. They can erase your hard drive etc. The thing is that if there is possibility to abuse single responsibility. It's abused sooner or later. Helpers are just another place to escape single responsibility (generally more places means more ways to do wrong things). That's the whole point of StringTemplate. It tries to minimize the possibilities of this happening. It cannot protect if you write models that have ToString methods that do shitty things or if controller implementer writes things like view.title = " ****Title "; But as general principle and advice, your blog entry is right on target! In real world, people will abuse these instructions whatever you say to them. It's more than possible that people that understand this clearly, do make shortcuts. Some by mistake, some by not thinking about it and some when they are overloaded and near deadlines. If adhering single responsibility makes you do more work than it is needed without adhering to single responsibility, it's more than likely that these "mistakes" happen. This is a relatively small mistake on scale of mistakes that you can do in your programs (security, performance, usability, etc.). "I am sorry, but there isn't really a good way of isolating designers when you move beyond the simple databinding scenarios." Or we have not yet found one. The problem with helpers and presentation models is that these are usually programmed by the same programmer that has written the models and controllers. They are not manageable by web designer who needs them or needs to modify them. If web designer knows (as one should) Javascript, then there is one possibility: provide web designers easy way to write their own server side helpers using javascript (without compilers etc.).

Ayende Rahien commented on Do not put presentation concerns in the controllers!

Wed, 31 Dec 2008 11:35:09 GMT

Bungle, Helpers are 100% part of the view logic. I don't see the distinction that you make here. TitleHelper.GiveMeFormattedTitleByUsingProduct is one option of what I think you should use. Another option, which is more friendly to designers, it to use a presentation model. Which take care of this. Presentation model is again, 100% view logic. I am sorry, but there isn't really a good way of isolating designers when you move beyond the simple databinding scenarios.

bungle commented on Do not put presentation concerns in the controllers!

Wed, 31 Dec 2008 11:29:24 GMT

You don't see problem here: <%= HTMLHelper.Escape(ProperCaseHelper.Convert(ASCIIHelper.EncodeFromUTF8(inv.ProductName))) %> Yes, you can write Helper like this: <%= TitleHelper.GiveMeFormattedTitleByUsingProduct(Product) %> Or do you have better ideas to implement the above and still maintaining the single responsibility? For me the above looks like shit. Helpers are shit because web designers don't usually write them. So whenever web designer needs something to be done to these model objects he/she has to ask programmer to write a new helper or modify the model to meet web designers requirements. Or he/she could write his own helpers using javascript hacks. If web designer agrees that Title (or part of it) is provided from the controller to make things easier for web designer, he/she probably says that it's ok that the Title is preformatted in controller. He probably never wants to make any changes on how it's rendered. And if you need to change it once a year, it's not a big deal to change it in controller code or some utility library the programmer has written for this.

Ayende Rahien commented on Do not put presentation concerns in the controllers!

Wed, 31 Dec 2008 11:09:56 GMT

> my example clearly demonstrates that the amount of code can easily become issue I am sorry, but I don't see this. Can you give a more expanded example?

bungle commented on Do not put presentation concerns in the controllers!

Wed, 31 Dec 2008 11:00:19 GMT

But my example clearly demonstrates that the amount of code can easily become issue in sense that it's not readable (maybe not even maintainable) and feels like bloat. So you either live with that kind of code or you loose single responsibility. The right choice depends on situation. I agree with you what you said about ASP.NET MVC samples regarding this conversation. It would not make samples more difficult to understand while still maintaining single responsibility aspects.

Ayende Rahien commented on Do not put presentation concerns in the controllers!

Wed, 31 Dec 2008 10:51:11 GMT

I didn't answer your question because it is focusing on the wrong place. The issue is not the amount of code being written, the issue is what you are doing in each place. The controller should perform some action and hand the view the information it needs to render itself. This is usually either the application model or a view model. The view make use of the model that the controller passed it to render itself. Making any decision that is required. Again, the distinction here is separation of concerns, having each bit only have a single responsibility.

bungle commented on Do not put presentation concerns in the controllers!

Wed, 31 Dec 2008 08:08:00 GMT

"responsibility of the class / method" Classes, methods etc. don't have responsibility. They are just code. Programmer who writes them might have. But that depends on programmer and other aspects that might lead to for example quick hacks.Your one-liner comments don't really help as you don't even try to answer the questions. I ask you again, how would you write the example I provided above and adhering single responsibility?

Andrew Hallock commented on Do not put presentation concerns in the controllers!

Wed, 31 Dec 2008 04:02:20 GMT

@Matías > There's no more presentation concerns in using a ViewData property named "title" than it is in using one named "invoice". Really? Exactly what HTML element does invoice refer to? None.

Ayende Rahien commented on Do not put presentation concerns in the controllers!

Wed, 31 Dec 2008 01:43:27 GMT

Aaron, Your description is accurate. The difference is in what you pass. If you pass presentation elements, like Title, then you are tainting the controller with presentation concerns. If you pass data that the view then use to present itself, this is another issue.

Ayende Rahien commented on Do not put presentation concerns in the controllers!

Wed, 31 Dec 2008 01:42:10 GMT

It is the responsibility of the class / method.

bungle commented on Do not put presentation concerns in the controllers!

Wed, 31 Dec 2008 01:10:35 GMT

"You are missing the most important part, the fact that it is not about the helpers, it is about the responsability" Do you mean responsibility of a programmer? Or responsibility of a layer? Can you then tell me how would you have implemented the pseudo code I provided above (the one with helpers)? The helper hell isn't an answer. But without helpers you get almost a passive view (well you might have some construct depending on your templating language). Let's make this simple with this PHP example: 1. controller is PHP code 2. view is PHP code 3. model is PHP code In every layer you have the full power of PHP language. There is no strict separation of things. In this case it is responsibility of a programmer or a web designer to do the proper things in these layers. And this is what you are suggesting here. But we do not live in a perfect world, nor is MVC or anything else a silver bullet. This is direct quote from the string template discussion I linked above: """ Bill Venners: So it comes down to what you think is realistic. If programmers do believe that view and model should be separated, why can't they do it with JSP or Velocity? Why can't they discipline themselves? Terence Parr: Oh, they could, but it never happens. That is the problem. Bill Venners: Why? Terence Parr: It is some psychological thing. Everybody knows we shouldn't speed: it's bad for gas mileage, it's dangerous. But not everyone agrees that speeding is always a bad thing. """

Aaron Powell commented on Do not put presentation concerns in the controllers!

Tue, 30 Dec 2008 22:25:31 GMT

But doesn't there need to be some point in which the controller determines what data will be available on the view? Isn't that the point of the controller to provide an interface to say a DAL, which isn't available at a view level? Or am I mixing MVP too much with MVC?

Ayende Rahien commented on Do not put presentation concerns in the controllers!

Tue, 30 Dec 2008 20:35:27 GMT

Passive view requires communication with the controller. In Web MVC world, the controller hand off control of the request to the view and die. It is also not much use when you are talking about views that are mostly string rendering than anything else.