MVC Обработка вложенных методов действий? - PullRequest
Новая
       29

MVC Обработка вложенных методов действий?

3 голосов
/ 13 ноября 2011

У меня есть класс Project, который содержит одну или несколько проблем: 

public class Project
{
    public int Id {get; set;}
    public string Name {get; set;}
    public List<Issue> Issues {get; set;}
}

public class Issue
{
    public int Id {get; set;}
    public string Description {get; set;}
}

У меня проблемы со структурированием моего приложения mvc, чтобы проблемы были вложенным элементом проектов на маршрутах URL?

/projects/details/1/issues/ - Display list of project issues
/projects/details/1/issues/1 - Display issue #1
/projects/details/1/issues/2 - Display issue #2
/projects/details/1/issues/create/ - Create a new issue for project #1

Моя первоначальная мысль состоит в том, чтобы создать маршрут, который приведет к следующему методу действия 

public ActionResult Details(int projectId, string action)
{
    if(action =="issues")
    {
      //Call ActionMethod...
    }
}

Но он просто не кажется правильным.Какие-либо предложения?Правда ли, что что-то подобное возможно с RoR?

Ответы [ 2 ]

5 голосов
/ 13 ноября 2011

Вы можете указать маршрут для этого действия следующим образом: 

routes.MapRoute("ProjectIssues",
                "projects/{projectID}/issues/{issueID}",
                new { controller=Projects, action=Details});

Тогда запросы типа http://domain.com/projects/3/issues/5 будут сопоставлены вашему действию Details в ProjectsController.

Вы можетеполучить параметры с одинаковыми именами параметров в маршруте 

public ActionResult Details(int projectID,int? issueID)
{
    if(issue.HasValue)
    {
        return RedirectToAction("IssueDetails",new {ProjectID=projectID,IssueID=issueID});
    }
    else
    {
        return RedirectToAction("AllIssues",new {ProjectID=projectID});
    }

}
0 голосов
/ 13 ноября 2011

Вероятно, вы упускаете точку MVC. Речь идет о разделении интересов, а не о вложенных доменах

Ваша идея хороша, но вам нужно реализовать Strategy design pattern, чтобы иметь чистый код.

Хотя Issue и Project напрямую связаны друг с другом, но они находятся в другом домене. Итак, лучше разделить их на разные контроллеры. Вы будете связывать свои проблемы , когда будете иметь дело с вашим Project контроллером и наоборот для Issue controller

Мое предложение будет для

  • Показать проблемы проекта - /Issue/Details/1 //here 1 is the project number
  • Показать один выпуск - /Issue/View/1/101 //1 is the project number and 101 is issue number
  • Создать выпуск - /Issue/Create/1 //1 is the project number

Это только мои мысли. Пожалуйста, не стесняйтесь спорить о моей методологии.

...