Ayende @ Rahien

Ayende Rahien commented on Why seperating the View / Controller is important

Thu, 08 Feb 2007 10:42:30 GMT

MVC can also use: bool isVisible = controller.IsUserAdmin; But in general, this is true. Take into account that there is a large number of issues that cannot be cleanly solved using the ASPX (painting a grid, etc), which cause this issue.

Chris van de Steeg commented on Why seperating the View / Controller is important

Thu, 08 Feb 2007 10:24:47 GMT

Yes, I know that's a bad thing, but I still believe the controller isn't that much of a difference. Take your example of showing an admin link or not. The controller has to know that the view wants information about if a user is an admin or not. So the controller in doesn't know about the view technically, but the programmer has to build the controller exactly so that the view can use it. This leads to having to know what the view does (and what info that needs) when programming a controller. To compare to codebehind again: - mvc:The controller sets a property: YES this user is an admin, which the view can then use. and the view uses isVisible='propertyBag["isAsmin"]' - aps.net: The view uses isVisible="IsAdmin()" the codebehind checks some BL service to see if the user is an admin or not. Hmmm.. writing this down, I think I see what you mean. Of course, if the codebehind uses button.visible = IsAdmin (something I don't tend to use, I prefer doing that in the HTML/aspx) THEN you're mixing up logic with display. So, if you use codebehind the 'right' way, it wouldn't be mixing it up. But mvc forces you not to use it the wrong way.... hmm...

Ayende Rahien commented on Why seperating the View / Controller is important

Thu, 08 Feb 2007 09:26:52 GMT

The difference is that the controller is explicitly not about presentation logic. The code behind class often has to deal with a lot of presentation logic (if the user is admin, show admin link, if I have permission to edit this post, show edit button on the grid, etc). This means that there is a high chance of mixing the business and presentation concerns, and that is a Bad Thing.

Ayende Rahien commented on Why seperating the View / Controller is important

Thu, 08 Feb 2007 09:26:52 GMT

Ayende Rahien commented on Why seperating the View / Controller is important

Thu, 08 Feb 2007 09:19:33 GMT

Ayende Rahien commented on Why seperating the View / Controller is important

Thu, 08 Feb 2007 09:16:50 GMT

About the confirmation of comment posted, I know, I run into this sometimes, I'll look into it.

Chris van de Steeg commented on Why seperating the View / Controller is important

Thu, 08 Feb 2007 09:10:43 GMT

//OT: At least, that was yesterday, seems to work now, sorry 'bout that

Chris van de Steeg commented on Why seperating the View / Controller is important

Thu, 08 Feb 2007 09:09:59 GMT

Perhaps I just don't see the light yet, I mean what's the big difference (imho only a small difference): - if you have a very specific controller for a view, the view knows about it's controller and can ask extra info from it. In turn, the controller asks it's info from BL services. - or you have codebehind class which you can ask info from, which in turn asks from the BL services. I would see a difference if the controller contained logic of any kind, that wasn't in the service. But all examples I see, just pass a request directly to a BL service and then pass that info to the view. The same way I do with my codebehind files. If it contained logic, you could use the same controller for several view, thus I'd see a PRO for mvc, but not without it. With MVC: controller <->view controller <-> BL service With ASP.net: view <-> codebehind class codebehindclass <-> BL service //OT: I don't get any confirmation that my comment is posted on your blog

Ayende Rahien commented on Why seperating the View / Controller is important

Thu, 08 Feb 2007 06:00:15 GMT

MonoRail is beta not because it has bugs, but because we want to reserve the right to make changes to it. Once we release it we will have to be much more concerned about backward compatibility. There are numerous places that already use it for production. There are several other projects that does MVC on ASP.Net, Igloo is the best of them in my opinion, and it still doesn't come close to the ease of use and the clean feel of MonoRail

Steve commented on Why seperating the View / Controller is important

Thu, 08 Feb 2007 04:30:34 GMT

I do like what I see with Igloo by the way - very nicely done. I'd like to learn more

Steve commented on Why seperating the View / Controller is important

Thu, 08 Feb 2007 04:26:04 GMT

I've reviewed the Monorail site at Castle. I'm very curious, but I get the sense it's not quite ready to be used, etc.. So, hopefully when it becomes a release out of beta I can take a look at it again. Is there a reason it's still just 'beta'? Is that because it's not done yet or it has bugs, etc... ? Is there any other MVC available for asp.net ? The one area I'm really enjoying with asp.net is the new Atlas and the toolkit.. It saves me hours of time. I'm not much of a javascript programmer, and I find these controls give me much of what I need on the client side without much effort

Ayende Rahien commented on Why seperating the View / Controller is important

Wed, 07 Feb 2007 21:13:03 GMT

I don't think that I agree with you on that. If the view starts calling random services, it is starting to get into the realm of too much logic. I don't have an issue with specialized controllers, though. In general, I don't like the idea that a controller knows about a view, so what I will usually do is to have the view pull the controller (and only the controller) for the data its needs. In the scenario that you give, I would usually add a method GetComments() to the controllers, other views do not need it and can safely ignore it.

Chris van de Steeg commented on Why seperating the View / Controller is important

Wed, 07 Feb 2007 20:49:06 GMT

What I dislike about MVC against classic asp.net, is that the controller pushes it's information to the view, as where I want the view to be able to pull it's information. Let's say the blog example. You have a view that lists all blogitems. The controller pushes this blogitems. Later on I decide I want the reactions to be displayed on the same page/view. So I first have to modify my controller to get these items (good bye re-usability of the controller, since other views might not use it), and then modify. If I have views/pages/aspx files that are service aware, I can modify just the view to access the commentsService and call the getMethod of it to have my data to present.

goodwill commented on Why seperating the View / Controller is important

Mon, 05 Feb 2007 15:43:38 GMT

Steve, IMHO, I think the main difference is who got the request. In web form the request are very scattered (all post back activity, plus entire form involved) and it goes thru a 1x steps page cycle with different lifetime for object availability (the famous one is the missing DataItem in GridView, dynamic control creation with missing state data, etc.). In MR, you got entire form data organized into a simple controller method, usually with very few parameters because of the binding is able to create the specific object and map it back to the corresponding method call. So its far easier to deal with than WebForm. Imagine filling in a contact person, you would end up doing: public void Button_Click(object sender, EventArgs e) { ContactPerson cp=new ContactPerson(); .. .. (lots of field mappings) cp.Save(); } (Dont say object data source- you end up with even less flexibility, lots of tricks to deal with the special fields, and lots of aspx xml to write.) With MR, you are doing: public void Save([ARDataBind("formContactPerson")] contactPerson) { contactPerson.Save(); } All the field mappings are done. And because the nature of HTTP request, MR is a more natural way to look at it, and you don't lost any flexibility to deal with the HTML/JS directly, such as employing prototype js/Scriptaculous/3rd party JS calendar. And you are not binded to MS only solution.

Steve commented on Why seperating the View / Controller is important

Mon, 05 Feb 2007 15:27:38 GMT

Where is the hiding of the button code ? I ask this only in that if you take the .cs code behind and move it to a different class you'd have: public bool AllowComments() { if(user.IsInRole("admin") || blog.Owner == user || comment.Author == user) { return true; } } then in the code behind: bool allowComments = AllowComments(); if(allowComments) { btnEditComment.Visible = true; } I guess what I'm wondering is if this is more of a question of 'where to I put my business logic'. The aspx/cs model can work as long as you don't clutter it up with business logic - in other words, it handles the decision of whether or not to display a button - it doesn't know much more than that. I think that is more of a good design principle?

Ayende Rahien commented on Why seperating the View / Controller is important

Sun, 04 Feb 2007 18:37:48 GMT

Monorail would have something like: BlogController.cs ============== public void ShowPost(int id) { // get post, etc PropertyBag["canEditComment"] = user.IsInRole("admin") || blog.Owner == user || comment.Author == user; } showPost.brail - view ================= <% if canShowPost: %> ${Html.LinkToAction('Foo','Bar', postId)} <% end %> The logic about if I should show it and HOW I show it are completely different things.

Steve commented on Why seperating the View / Controller is important

Sun, 04 Feb 2007 17:42:21 GMT

Good response. Take your example - how does Monorail do that same task? This could be a deciding factor for me as a traditional webform developer.

Ayende Rahien commented on Why seperating the View / Controller is important

Sun, 04 Feb 2007 06:46:03 GMT

Because the CS is often doing a LOT of stuff that is directly related to the presentation. At that point it is no longer usable for me. A simple example: if(user.IsInRole("admin") || blog.Owner == user || comment.Author == user) { btnEditComment.Visible = true; } There is a business logic here (who can edit a comment) and presentation logic, showing / hiding the edit comment button. Take a complex page, now try to dechiper where are the business logic you need to modify, and why you are doing this or that. Add complex presentation logic, and you are set for a failure.

Steve commented on Why seperating the View / Controller is important

Sat, 03 Feb 2007 23:14:23 GMT

Why do you not think that Webforms separate the view/controller ? The aspx is the view, the cs is the controller. I could go a stretch and say an objectdatasource is the model :)