Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Is it considered a bad practice to use code-behind with ASP.NET MVC Views? Got into a bit of a debate about this with my colleagues today and I was wondering the community’s thoughts.
Obviously, this isn’t an option when using another MVC like Rails, which makes me think it’s relied on more as a crutch for those accustom to working with traditional ASP.NET Web Forms applications.
I used code-behind extensively on my first ASP.NET MVC (Preview 3!) project – primarily for doing stuff like casting ViewData[“foo”] into strongly-typed data objects, gathering view data into IEnumerables so I could loop across it, that kind of thing.
With the introduction of strongly-typed views, and pragmatic use of the (horrifically-named) Model-View-ViewModel pattern, I haven’t missed code-behind at all since it was removed from the project framework just before the final release.
I now strongly feel that whatever processing you’re doing in your view’s code-behind, you are far better off modelling the result of that processing in your ViewModel, allowing the controller to perform the actual processing, and keep the view as simple and lightweight as you can. That’ll let you test the processing logic, it makes the views easier to modify, and creates – I think – a much more elegant separation between transforming your data for display, and actually displaying it.