ASP.Net MVC View Structure

Question

I just finished Scott Gu's Nerd Diner tutorial. I found it very helpful because it not only taught the basics of ASP.Net MVC, but also how to use with Repositories, Validation, Unit testing, Ajax, etc.. Very thourough, but still manageable.

However, I am curious about his site structure:

Specifically, he used this view strucuture for every object:
/ModelObject/Edit/
/ModelObject/Create/

Then extracted the common elements between the two views and put them into a partial.

I understand the logic, but it seems like it would lead to "view explosion" if you have even a moderate number of tables in your database.

Scott's really good, so I am assuming his structure is right. But I would like to know why.

Thanks!

[Edit for clarification]

I realize that many times it is necessary for there to be multiple actions (and views) to handle differences in creates and edits. It is the case of the very simple edit and create, where the only difference between the two actions is in one case the model has an ID and needs to be updated, and in the other case the model does not, so it needs to be inserted.

In this case, is the violation of the "Dumb View" rule by using the same view to handle both cases going to cause major problems?

Answer 1

if you have a background as asp.net webforms developer, your answer is natural. There are several questions, it depends on the point of view. At first, with asp.net-mvc we do not have fully-equiped server controls making many things for us, without a real awareness what they do. Now you have to type more code and have eyes like a surgeon on html.This way I can find a reasonable question for "view explosion" Other projects follow more or less that structure, see the project by Rob Conery: Mvc Storefront

PS: "Skinny controllers, Fat Model and… Dumb view"

[Update response to clarification]

Mhh.. I think there's no violation of "dumb view". The important thing is that the all the views has nothing to do with the code in the business logic layer or in your model. You can a have a button "Save", it is the controller has to know which action must be executed, insert or update.

Answer 2

It is true that this can indeed lend itself to a lot of views. However, I've found that in my real life applications, I'll have a number of tables that I don't have a 1:1 correlation to CRUD operations. While I certainly have data that goes into those tables, I've found that most times a view presents data from at least two if not three or more tables. Just like every other application, you've got to know what you're after so that you can plan things out. Any large size application is going to require quite a bit of planning up front (which would include analyzing the number of views/controllers for MVC).

It's only the small apps that you can sling together based on you hunches and past experience.

Answer 3

The view structure is based on the controllers, not the model directly. In the Mvc methodology, you should have a view for each action (each public method, essentially) in a controller. The controller actions don't have to match up directly to each table in database but there is likely some sort of direct relationship between the number of tables in the database and the number of controllers and views. Controllers are higher level

It is standard to have CRUD type actions on the controller, when they are applicable:

• Index: list the items
• Details: view a specific item
• Edit: edit an item
• Create: new item
• Delete: delete an item

Each of these actions will require a view (and sometimes more than one).

So, yes, you can collect a large number of views if it is a large application. The way to minimize the code is:

• Extract shared functionality to partial views, as to keep the action views as small and simple as possible
• Keep the views and controllers simple so that they are easy to maintain
• Use AJAX to implement more functionality in one view

It's important to point out that any large application is going to have lots of forms. Whether it's Mvc or Web Forms, if there is a lot of data to work with, there are going to be a lot of forms necessary to do it.

Answer 4

On more reflection, this is what I am thinking:
Combining the edit/create views would be easy on simple models because

- Same properties displayed
- Same validations

BUT doing this would force you to either

- handle both the update and insert in the same action
- use a control statement in the view to determine which view action is used to update

Both options seem ugly and unnecessary when it is so easy to use separate actions and separate views with common code extracted into a partial.