Code behind in ASP.NET MVC

Question

What is the purpose of the code behind view file in ASP.NET MVC besides setting of the generic parameter of ViewPage ?

Answer 1

There isn't a purpose. Just don't use it except for setting the model

ViewPage<Model>

See this blogpost for more info.

Answer 2

This is a great question. Doesn't MVC exist in the ASP.NET environment, without using the specific MVC pattern.

View = aspx

Controller = aspx.cs (codebehind)

Model = POCO (Plain Old C#/VB/.NET objects)

I'm wondering why the added functionality of MVC framework is helpful. I worked significantly with Java nd MVC and Java Struts several years ago (2001), and found the concepts in MVC to be a solution for the Internet Application organization and development problems at that time, but then found that the codebehind simplified the controller concept and was quicker to develop and communicate to others. I am sure others disagree with me, and I am open to other ideas. The biggest value I see to MVC is the front controller pattern for Internet development, single entry source for Internet Application. But, on the other hand, that pattern is fairly simple to implement with current ASP.NET technologies. I have heard others say that Unit Testing is the reasoning. I can understand that also, we used JUnit with our MVC framework in 2001; but I have not been convinced that it simplifies testing to use te MVC framework.

Thanks for reading!

Answer 3

At this Blogpost is a working example of removing the code behind. The only problem I'm stuck with is that it is not able to set namespaces on the class.

Answer 4

The codebehind provides some of the strong typing as well as the intellisense support that you get in the view. If you don't care about any of these two features, you can remove it.

For example, I typically use the NVelocity ViewEngine because it's clean and pretty straight forward.

Answer 5

Ultimately, the question you ask yourself is this:

Does this code A) Process, store, retrieve, perform operations on or analyze the data, or B) Help to display the data?

If the answer is A, it belongs in your controller. If the answer is B, then it belongs in the view.

If B, it ultimately becomes a question of style. If you have some rather long conditional operations for trying to figure out if you display something to the user, then you might hide those conditional operations in the code behind in a Property. Otherwise, it seems like most people drop the code in-line to the front end using the <% %> and <%= %> tags.

Originally, I put all my display logic inside the <% %> tags. But recently I've taken to putting anything messy (such as a lengthy conditional) in my code behind to keep my XHML clean. The trick here is discipline - it's all too tempting to start writing business logic in the code behind, which is exactly what you should not be doing in MVC.

If you're trying to move from traditional ASP.NET to ASP.NET MVC, you might aviod the code behinds until you have a feel for the practices (though it still doesn't stop you from putting business logic inside the <% %>.

Answer 6

Here's my list of reasons why code-behind can be useful taken from my own post. I'm sure there are many more.

• Databinding legacy ASP.NET controls - if an alternative is not available or a temporary solution is needed.
• View logic that requires recursion to create some kind of nested or hierarchical HTML.
• View logic that uses temporary variables. I refuse to define local variables in my tag soup! I'd want them as properties on the view class at the very least.
• Logic that is specific only to one view or model and does not belong to an HtmlHelper. As a side note I don't think an HtmlHelper should know about any 'Model' classes. Its fine if it knows about the classes defined inside a model (such as IEnumerable, but I dont think for instance you should ever have an HtmlHelper that takes a ProductModel. HtmlHelper methods end up becoming visible from ALL your views when you type Html+dot and i really want to minimize this list as much as possible.
• What if I want to write code that uses HtmlGenericControl and other classes in that namespace to generate my HTML in an object oriented way (or I have existing code that does that that I want to port).
• What if I'm planning on using a different view engine in future. I might want to keep some of the logic aside from the tag soup to make it easier to reuse later.
• What if I want to be able to rename my Model classes and have it automatically refactor my view without having to go to the view.aspx and change the class name.
• What if I'm coordinating with an HTML designer who I don't trust to not mess up the 'tag soup' and want to write anythin beyond very basic looping in the .aspx.cs file.
• If you want to sort the data based upon the view's default sort option. I really dont think the controller should be sorting data for you if you have multiple sorting options accessible only from the view.
• You actually want to debug the view logic in code that actuallky looks like .cs and not HTML.
• You want to write code that may be factored out later and reused elsewhere - you're just not sure yet.
• You want to prototype what may become a new HtmlHelper but you haven't yet decided whether its generic enough or not to warrant creating an HtmlHelper. (basically same as previous point)
• You want to create a helper method to render a partial view, but need to create a model for it by plucking data out of the main page's view and creating a model for the partial control which is based on the current loop iteration.
• You believe that programming complex logic IN A SINGLE FUNCTION is an out of date and unmaintainable practice.
• You did it before RC1 and didn't run into any problems !!

Yes! Some views should not need codebehind at all.

Yes! It sucks to get a stupid .designer file created in addition to .cs file.

Yes! Its kind of annoying to get those little + signs next to each view.

BUT - It's really not that hard to NOT put data access logic in the code-behind.

They are most certainly NOT evil.