In the current examples on ASP.NET MVC I see quite basic entities, with simple CRUD methods.
But I\'m not sure about what to do with more advanced models. Let me give an
Your "CarPart" entity (class CarPartModel) can be in "stock" state (class StockCarPartModel : CarPartModel) or "replaced" state (class ReplacedCarPartModel : CarPartModel). Then:
This all is handled by "Default" route and in your CarPartController your have actions:
public ActionResult Index() { ... }
public ActionResult Replaced() { ... }
public ActionResult ByCar(string carId) { ... }
public ActionResult Inventory() { ... }
I think your controller is not fat. It is normal for controller to deal with Model inheritance. The main complexity will be in your ViewModels and Views
Your design should initially focus on the entities. You have car
, employees
and inventory
. Write a controller for each one of these. That will give you the basic routes:
/cars/{action}/{id}
/employees/{action}/{id}
/inventory/{action}/{id}
From here you should be able to write a new route with a custom route constraint with the following structure:
/cars/{id}/part/{id}/
This is also slightly better than /cars/{id}/carpart/{id}
because the word car in carpart
is redundant. /car/.../part/
indicates that part is for a car.
Thinking about things like these for URI design is really important early on because changing the URI design later will break search engine indices, bookmarks and links.
If you wish to use the kinds of paths you provided in your example, then it sounds like you should learn how to use the Routing engine in .NET 3.5. You should be able to use the kinds of urls you need, but you will need to create several custom routes and probably a custom route handler to accomplish it. The Routing engine in .NET 3.5 is very flexible and was not designed specifically for MVC...its actually very generic and can provide a very broad, probably unlimited range of url rewriting.
Its a bit late where I live, so the example I was trying to write just isn't forming. :P Suffice to say, a custom route handler and some new route mappings should get you where you need to be.
EDIT: This may be of help:
http://codingcockerel.co.uk/2008/05/26/custom-routing-for-asp-net-mvc/
EDIT 2: I left out controllers before. The routing just gets you the ability to use the kinds of URLs you want. And thats a good thing...the kinds of URL's you proposed will provide a better SEO experience long-term. As for organizing your controllers, I recommend keeping it simple:
/Controllers/CarsController.cs
/Controllers/PartsController.cs
/Controllers/EmployeesController.cs
/Controllers/InventoryController.cs
Your routes would match your url patterns, and turn them into a proper route to your controller, taking the ID's and matching them to the parameters of your actions.
EDIT 3:
So, now that I understand your question more fully, I hope I can answer it better. Generally speaking, I think controllers should map 1:1 with your entities. If you have a GeneralPart, then you should have a controller dedicated to managing general parts. If you have CarPart, then you should have a controller dedicated to managing car parts. If CarParts are GeneralParts, and they can behave like GeneralParts in some cases, then it is probably best to have those management aspects on the GeneralPartsController, unless that management deals with any special attributes of a CarPart...in which case management should be delegated to CarPartsController. It is kind of elegant how polymorphism plays into controller organization, and how the "is a" relationship allows you to reuse controllers to manage multiple types.
To be honest, you have a fairly complex scenario I havn't directly encountered in my time working with ASP.NET MVC. I try to avoid such scenarios as much as possible, because they give rise to complicated questions like this that tend to be subjective in their answers. Ultimately, you should organize your controllers in a way that makes logical sense to how they are used, how they map to your entities, and how well they organize the behavior you are interested in exposing. Sometimes, it isn't logical to map all of your controllers to a single entity. Sometimes you need to have a "composite" controller that deals with actions that operate on multiple entities at once, or graphs of entities. In these cases, its probably best to have controllers dedicated to those particular behavioral groups, rather than trying to find one entity-specific controller that "sorta fits".
I would recommend using Restful Routing for ASP .NET MVC:
https://github.com/stevehodgkiss/restful-routing
You don't need to have too many things going on in a controller.
Think of a controller as a class that determines what the user wants and what it should see in the end.
What user wants is determined by the ASP.NET MVC engine automatically for you, with the help of the routes you defined in the Global.asax file. Then the controller should decide what view the user should see as a result of the request he/she made.
So for your application things would go something like this :
Global.asax
routes.MapRoute("Cars", "cars/{id}/{action}",
new { controller = "Cars", action = "Details", id = "" } );
//This route should give you the URLs you listed on your question
CarsController.cs
public class CarsController : Controller {
//this action will be called for URLs like "/cars/423"
//or /cars/423/details
public ActionResult Details(int id) {
//You would most likely have a service or business logic layer
//which handles talking to your DAL and returning the objects
//that are needed for presentation and likes
Car car = SomeClass.GetCar(id);
if (car == null) {
//if there's no car with the ID specified in the URL
//then show a view explaining that
return View("CarNotFound");
}
//if there's a car with that ID then return a view that
//takes Car as its model and shows details about it
return View(car);
}
//this action will be called for URLs like /cars/423/edit
[AcceptVerbs(HttpVerbs.Get)]
public ActionResult Edit(int id) {
//again get the car, show an edit form if it's available for editing
}
//this action will be called for URLs like /cars/423/edit too
//but only when the request verb is POST
[AcceptVerbs(HttpVerbs.Post), ActionName("Edit")]
public ActionResult Save(int id) {
//save the changes on the car, again using your business logic layer
//you don't need the actual implementation of saving the car here
//then either show a confirmation message with a view,
//saying the car was saved or redirect the user to the
//Details action with the id of the car they just edited
}
}
So basically this is how you would set up your controller(s) for an application like that.