레일에서 편리하게 MVC를 사용합니다.

Question

저는 현재 한 번의 업데이트 작업으로 작성자, 번역, 관련 기사 등 모든 기사 관계를 관리하는 기사 컨트롤러를 보유하고 있습니다.

페이지에는 검색 및 정렬 기능, CRD 작업, 새 연결 만들기 및 기존 연결 레코드 관리 양식이 포함 된 일련의 "목록"이 포함되어 있습니다.

이 모든 것들은 ArticleController 편집 및 업데이트 작업과 각 목록의 부분 템플릿 묶음으로 관리됩니다.

관련 검색 레코드를 찾기 위해 추가 검색 테이블을 추가하여 기능을 더 확장하고 싶습니다. 나중에 다른 기능을 추가하겠습니다.

이런 식으로 (한 편집 페이지에서 모든 협회 관리) 편리하다고 생각합니다. 따라서 다음과 같이 각 목록에 대한 특수 컨트롤러를 만드는 것이 더 좋습니다.

/articles/1/edit/authors 

그리고이 컨트롤러의 이름은 무엇이되어야합니까? ArticleController 또는 PeopleController 또는 ApplicationController의 자식이어야합니까?

아니면 모든 괜찮 나는 편집증입니까?) 모든 MVC 조건이 sctictly 충족

UPD. 질문 :

하나의 컨트롤러에서 모든 관계를 관리하는 것이 좋습니까? 관계를 추가/삭제할뿐만 아니라 @ article.authors.find_or_create_by_name (name)과 같이 newone을 생성하는 경우도 있습니다. 보기의 관계는 단순히 선택 태그가 아닙니다! 자체 검색, 정렬, 페이지 매김 기능을 갖춘 완벽하게 보호 된 테이블입니다.

는 "subcontroller"를 만드는 방법 : 우리가 ArticleController 및 편집 작업이있는 경우 누군가가 나를 이해 해달라고하면

는 다른 방법으로 문의 할 수 있습니다. ArticleController는 Article 모델의 필드 만 관리해야합니다. 그리고 많은 수의 하위 컨트롤러가 관계를 관리해야합니다.

왜 내가 필요합니까? AJAX를 이러한 페이지에 추가 할 수 있습니다. 심각한 문제는 발생하지 않지만 모든 AJAX 호출에서 ArticleController.update/edit 작업을 쿼리하면 모델에 대한 Arel 관계 구축과 같은 일종의 unnessesary 작업을 수행 할 수 있습니다. 나는 일을 작은 독립적 인 조각으로 나누고 모든 것을 할 수있는 거대한 한 명의 컨트롤러를 만드는 것을 좋아하지 않습니다.

Answer 1

당신이 기사 controller은 관계를 관리해서는 안됩니다. 귀하의 model에 있어야합니다. 활발한 기록 callbacks을 살펴보십시오. 콜백에서 작성자, 번역 등을 관리하는 것과 관련된 모든 것을 할 수 있습니다. 예를 들어, after_updatecallback

또한 nested resources을 사용하려고합니다. 예를 들어 authors은 내면에 내포되어 있습니다. articles

Answer 2

예를 들어 저자 < -> 기사 관계를 관리 할 소유권 관리자가있을 수 있습니다. "조인"모델을 사용하여 관련된 두 모델 간의 관계를 처리 할 수 ​​있다는 것을 잊지 마십시오.

edit_article_authorships GET /articles/:article_id/authorships/edit(.:format) {:controller=>"authorships", :action=>"edit"}