views:

34

answers:

1

Hi everyone,

i need to make a form wizard of 3 steps. Each steps can be saved in the database separatly. The steps will be to enter information about an Company, then his Publications and finally his Reservations.

Should i put all the logics in one controller or different controllers? My first thought would be in one controller since this is all about managing a company but the problem with that is i will have a lot of code in the controller and in the View folder, i will have like 20 webpages.

Is there a way to put subfolders in the View\Companies\ folder so i could have View\Compangies\Publications. That way, i can separate the web pages for each theme.

Or how do you manage that? Is there a better way to handle properly Wizard Forms?

alex

+1  A: 

Depends on the Model. If your Publications are their own entity and they eventually get stored (in DB) in their own table, it might be the proper way for them to have their own controller. The same with Reservations. If you store both of those as a part of the Company entity then it might be better for them to stay in Company controller. But it seems to me that they ought to be separate.

With regards to redirection between controller actions you can always use RedirectToAction() to redirect inside the same controller.

You can also use MVC Futures project and their RedirectToAction() extensions with which you can also redirect between different controllers.

FWIW, I think that if you are editing Publication that has its own properties etc. it belongs in their own Entity and as such they need to have their own Model, Controller and subsequently Views (in a separate View folder at the root of Views).

UPDATE:

What's wrong with a route looking like this:

Creating a publication for a company with {companyId}

/Publication/Create/{companyId}

or

Editing a publication with an id {publicationId} and for a company with {companyId}

/Publication/Edit/{companyId}/{publicationId}

or if publication ID's are unique regardless of the company

/Publication/Edit/{publicationId}
mare
Sorry, just figured out that RedirectToAction() extensions are in MVC Contrib not in MVC Futures. http://mvccontrib.codeplex.com/documentation?referringTitle=Home
mare
Well, you can't go to a Publication if you havent selected the Company first. But the Publication have his own logic so maybe it could be separated.Could i do something like this in my solution:Project/Controllers/Companies/CompaniesController.cs,Project/Controllers/Companies/Publications/PublicationsController.cs,Project/Views/Companies/Index.aspx,Project/Views/Companies/Publications/Index.aspx.And the url could be:localhost/Companies,localhost/Companies/1/Publications
Alexandre Jobin
I think you could but I don't like it. It's complicating the structure. Preventing to go into the Publications editor can be done by checking the Route data (check if the company ID is null in route data) or by storing the selected company (i.e. company ID) in the Session or any other way you might come up with.
mare
the reason why i wanted to do it that way is because im not managing Publications. Im managing Companies that have Publications. If someday the client needs to manage Publications, i will do it /Publication/Edit/. Well maybe your right too. I don't know for sure what i will do :)
Alexandre Jobin
Do it as you wish but you will soon find out that you will have to shift your thinking when working with ASP.NET MVC. You are not managing Companies with Publications, you are always managing a certain Publication for a certain Company. It fits perfectly to your requirements because you can always check if the {companyId} parameter was provided. And it is much more simple in design.
mare
To further explain my point, I find it misleading and wrong using plurals in MVC routes like you do Companies, Publications etc..you can check out many MVC samples and you will find out that they generally deal with an Entity..so singular. I think that's one of the premises with MVC.
mare
please post some details about data persistence, how you actually store this in datastore? Let's see what implications the DB design brings to the application design (not that it should influence your Model Entities design but it may, eg. it is nothing wrong with it if it does)
mare