I like this concept, I want to go to /Project/ProjectId/Tasks and see a filtered view of tasks for that Project. Personally, I don't mind, however, if the "item specific" views (e.g. details / show / update / etc) are back at /Task/TaskId.
I do, however, see how it could be beneficial for "dependent" types, such as when a task can't exist without a Project, for them to be accessed via /Project/ProjectId/Tasks/TaskId.
To implement my version, I have an Action in the Project controller as follows:
public ActionResult Tasks(string id)
{
Project projectToDisplay = Repository.GetProject(id);
ViewModel["Tasks"] = Repository.GetTasksForProject(projectToDispaly);
return View(projectToDisplay);
}
Obviously, this could be improved with a strongly typed ViewModel.
For reference, my repository (Entity Framework specific) has the following code:
public Project GetProject(int id)
{
return _entities.Projects.FirstOrDefault(m => m.Id == id);
}
public IList<Task> GetTasksForProject(Project project)
{
return _entities.Tasks.Where(m => m.Project.Id == project.Id).ToList();
}
Alternatively, with Entity Framework, you could just do the following in the repository:
public Project GetProject(int id)
{
return _entities.Projects.Include("Tasks").FirstOrDefault(m => m.Id == id);
}
And then the controller would just need:
public ActionResult Tasks(string id)
{
return View(Repository.GetProject(id));
}
which is a little bit more ViewModel-esque.
(NB: This code has been adapted to your project / task context, so it is not my actual code. If this code doesn't work or has errors, I apologise, I've effectively re-written it so there may be typos / etc.)