Why should I use inline coding to develop MVC ASP.NET?

Question

I reviewed some examples about MVC ASP.NET and all of them use the inline coding method.

Is there a big reason to use this method and ignore my preferred code behind method?

Answer 1

I think the main reason for this is that there really shouldn't be much logic there since it's only logic related to the view. When there's not much logic my opinion is that it reads better using the inline method. However if there was a view with lot's of loops and such using the code behind is certainly a viable option in my opinion.

Answer 2

In Scott Gu's recent blog about the MVC Release Candidate, they are having views not have code behind by default, which may be a reason you don't see that in samples.

Answer 3

A nice quote from Derek Whittacker. Couldn't but it better myself

Also refer to this identical Q on SO

"In standard Asp.net WebForms development the CodeBehind was meant to act as a page controller, but over the years it has turned more into a dumping ground for all sorts of evil code (ie business logic). It is this nasty, ugly code that has given (in part) WebForms a bad image. By continuing to use your code behind in MVC all you are really doing is taking an old nasty technique and applying it to new framework and in turn removing one of the great advantages of MVC.

Part of the beauty of the MVC pattern (notice I said pattern, not framework) is that it helps to enforce Separations of Concerns by pushing logic out of your view and into your controllers."

Answer 4

Dear redsquare, Derek's sound is good but I can show you a page that all of DataAccess and Business methods is a another layer, but the view is full of HTML fields (ASP.Net Components) and it's codes to view them. Notice that all of heavy code that I told you is only for view (UI Layer). This heavy code is too complex to place in line code. For small websites or web application, inline code is good but for big website or web application, I think it is not a good solution.