Using Code-Behind with ASP.NET MVC Views

Question

Is it bad practice to use code with ASP.NET MVC Views? I thought about it with my colleagues today, and I wondered about community thoughts.

Obviously, this is not an option when using another MVC, such as Rails, which makes me think that it relied more on a crutch for those who are used to working with traditional ASP.NET Web Forms applications.

Answer 1

I heavily used code for my first ASP.NET MVC project (Preview 3!) - primarily to create things like casting ViewData ["foo"] into strongly typed data objects, collecting view data in IEnumerables so I can loop through it, something like that.

With the introduction of strongly typed views and the pragmatic use of the Model-View-ViewModel (badly named) template, I did not miss the code at all, as it was removed from the project framework just before the final release.

Now I feel that no matter what processing you perform in your vision code, you are much better off simulating the result this processing in your ViewModel, allowing the controller to execute the actual process and save the presentation as simple and easy as possible. This will allow you to test the processing logic, it simplifies the change of views and creates, I think, a much more elegant separation between the transformation of your data for display and the actual display.

Answer 2

I would say that it is bad practice to use code delays with ASP.NET MVC. MVC allows you to share anxiety when the presentation logic (in the views) is separated from the application logic (in the controllers). Using code delays will mix presentation logic and application logic inside code delays, which can defeat some of the benefits of MVC.

Answer 3

Of course, ASP.NET MVC In Action authors advise against this, and I agree. This is not necessary, so why? At the beginning of the beta version, the code file was included, but it was deleted in RTM (or shortly before).

Typically, this simply encourages you to do more non-viewing than necessary in the view, as it is hidden from view / not to your liking.

Answer 4

Yes, the code word has long been a secret hideout of business logic, which, as we all know, should not be at the level of representation.

The code behind has been removed to stop enticing developers.

Answer 5

I would recommend avoiding code in an MVC application at all costs. Using the code behind overrides some of the values ​​you get with the MVC Framework, such as separation of concerns, etc. You want to have access to data, business rules, type conversions, and the things that apply to the model. If you find that you need to convert your data types, for example, the mentioned Dylan, you can create ViewModels. The ViewModel will basically present data from the actual model you want to display in the format in which you want to display it.

Answer 6

It is probably best to avoid putting anything in code when using MVC.
I would be interested to know what part is being discussed, go into the code word?

If you are new to Asp.Net MVC, I really recommend spending some time on the Nerd example. There is a free electronic unit and a source http://nerddinner.codeplex.com/ .

Creating a simple demo from scratch is a great way to find out.
After that, it can shed light on where the code that you have in the codeb can alternatively go.

Note. . If you follow EBook, take the last site.css file from codeplex, otherwise the virtual land maps will not be correctly aligned.

NTN
Ralph

Answer 7

It should be noted that "Code Behind" is a feature of the Web Forms viewer. This really has nothing to do with ASP.NET MVC itself.

For example, the Razor viewer in MVC3 does not even support it.

I would answer your question as follows: if you cannot switch view mechanisms without overwriting your controllers (or even your models), you are not using the MVC pattern correctly.

Probably most of what you do in the .aspx.cs file really needs to be done before the model (or View Model) is passed to the view. However, in the projects that I migrated from ASP.NET Web Forms to ASP.NET MVC, I left a lot of code behind. For example, I find it cleaner and more enjoyable to use the Repeater element than trying to use the "for" loop in Web Forms. I am still just repeating Model Model data. So why not? The separation of problems persists (perhaps more so in reality).

I mean, why is the “best practice” for Web Forms suddenly becoming the wrong way to view web forms? As a simple example, consider Repeater, which assigns a different CSS class to every second row of the table. Why should my controller (or even my model) care? Trying to put that logic into a web form quickly turns into a soup soup and full of spaghetti. Now imagine something more complex.

I left the master pages in place, which build the menus in code. Again, all the data comes from the view model. I do not understand why using a GridView or other controls in this case should also be a problem.

I usually turned off ViewState in Web Forms and bound the data in "Init". However, often there was a small ViewState, which I could not get rid of. I put some code in the "Render", which moves it around the form (by default it is by default). When switching to MVC, I sometimes left this code. So, I have ASP.MVC sites that really use Code Behind. I just try to make this code specific to the presentation.

In new projects, as a rule, I found that most pages do not require Code Behind. Fortunately, viewing engines like Razor made code mixing and markup on the network much less painful to write, read, and maintain.