Are ASP.NET MVC automated code good enough to be used in real live applications

Question

I have been trying to get my hands dirty with ASP.NET MVC which looks pretty good (I am not certain, but some users say that even StackOverflow and other StackExchange websites made use of it). The tutorial I am following is from asp.net, named MVC Music Store. It's a pretty fast paced tutorial and a good one too. The question that bother's me while going through the various tutorials available on this site including the MVC Music Store is the automated code used for developing them.

Like, this tutorial makes use of Entity Framework 4, which supports a development paradigm called code-first. You add an Entity class inheriting from Entity Framework database context , add two lines of code and it will handle our create, read, update, and delete operations for us.

public class MusicStoreEntities : DbContext
{
    public DbSet<Album> Albums { get; set; }
    public DbSet<Genre> Genres { get; set; }
}

Similarly, when I used the Scaffolding feature while adding a controller, like following :

It does a hell amount of work on its own :

• It creates the new StoreManagerController with a local Entity Framework variable
• It adds a StoreManager folder to the project’s Views folder
• It adds Create.cshtml, Delete.cshtml, Details.cshtml, Edit.cshtml, and Index.cshtml view, strongly typed to the Album class.

As you can see, the developer's life made a hell lot easier with this automation but the question remains is whether or not this automatic code is good enough for production development ? Does anybody use(Does SO) use them. Is there any downside associated with these codes or one should be encouraged to use them ?

Answer 1

When you want to work with ASP.NET MVC Scaffolding, you should consider these items:

1. The HTML tags are defined in scaffolding
2. The id and class attributes are defined already
3. The HTML tag nesting (like putting a <p> tag inside a <div> tag) is defined already
4. The HTML helpers are used by default

Because of these reasons, every time I used ASP.NET MVC Scaffolding in real applications, I found myself almost changing it all and replacing it with customized code (including nesting levels, HTML tags, id and class attributes for design and JavaScript purposes), using my own helpers, etc.

In other words, I was fund of scaffolding (or code-generation in general), but in real-world examples, I personally found them more time and energy consuming than writing from scratch.

---

One may argue that, you can create your customized scaffolding. Yeah, that's correct, and that was what we wanted to do as an alternative tool. Even Pluralsight has a good video on this topic. But unfortunately, we found ourselves implementing customized scaffolding instead of concentrating on the main business. This of course was not desirable for our team, and because each and almost every page of our application had a kind of different architecture, developers agreed to create the structure manually.

So, my answer, based on our team's productivity and above-mentioned reasons, is:

No, It's not good enough for real-world applications, and it actually slows you down.

Answer 2

The generated code is a starting point - it is designed to get you up and running as quickly as possible.

However, since it is generated it cannot take all possible considerations into account. It is just scaffolding.

The idea is to use this and build up on it to suit your particular needs, adding security, scalability, logging and whatever else you need.

SO does not use EF - their performance needs were not met by it. They have written (and open sourced) a light orm - Dapper, but many organizations do use EF.

Answer 3

There's a reason it's called Scaffolding. It's just there to reduce boilerplate code.

Here's what Webster says about the real life version:

Scaffolding: 1. A temporary structure on the outside of a building, made of wooden planks and metal poles, used by workers while building, repairing, or cleaning the building.

It's called scaffolding because it's not the real application. It's just a framework to help you minimize boilerplate code. Here's how to use the MVC scaffolding properly:

1. My app will be close to the scaffolding - Then generate the scaffolding and modify the code to how you see fit.
2. My app is nowhere near what the scaffolding provides and most controllers are very different - Sometimes it's so off the beaten path of a CRUD app that you need to take matters into your own hands. Just create a new controller and start coding. No harm done there.
3. My app is nowhere near the scaffolding, but each view and controller is very repeatable. - MVC scaffolding templates are very customizable, so much in fact that you can create your own! MVC uses T4 templates that are completely customizable, so if your company has particular coding standards you adhere to, or you want to include some extra boilerplate code inside the template, you can include those and have MVC generate those inside the controllers/views.

Answer 4

They quick answer is, yes, the code is good enough, but chances are you won't use it. The code is as good or even better as, for instance the way any other MVC framework like RoR or Django handle code generation.

The long answer is that in any real business application, you'll probably want to leave MVC3.NET for what it is good for, the presentation layer. You'll want to keep your EF data acces and your business logic on a separate library and just reference it on your MVC project.

This will go inline with separation of concerns and the real MVC pattern in order to keep your presentation layer code agnostic and your business code reusable.

EDIT: The why, for me, is what I mentioned before, working with the "true" MVC pattern and separation of concerns... The generated code from the MVC3 framework is tightly coupled with the presentation layer. If you later want to change your presentation or add a desktop interface, you can't reuse the same business logic. It's all about loosely coupled code.

Answer 5

I've found the scaffolded pages more than adequate for the in-house admin side, to get to market quicker. It may not meet the full needs of the users, but it's enough so that I can focus on the public-facing side. Once that is done, I can come back and make their admin pages prettier / more functional.