2016-07-05 3 views
1

Order has_many AItemsBItems입니다. 알 수 있듯이 항목은 기본적으로 동일하지만 별도로 분류하는 중요한 비즈니스 이유가 있습니다. 이 문제를 최우선 적으로 해결하는 전략이 무엇인지 궁금합니다. 나는 이것이 다소 냉소적이라고 생각하지만 ... 명백한 견해와 주장을 얻기를 희망한다.기본적으로 똑같은 2 개의 컨트롤러/모델/뷰를 건조하는 방법

보기 코드는 현재 나는 부분을 사용하고 있습니다.

class AItemsController 
    def new 
    end 
end 

class BItemsController 
    def new 
    end 
end 

# view files layout 
> views 
    > Items 
    > new.html.erb 

# routing 
get '/items/new/:type' 

# code for /views/Items/new.html.erb 
# code from partial evaluating the param[:type] instead of a passed object 

컨트롤러 코드

현재 : 전적으로 부분 없애 쉬울 그냥 같이 매개 변수를 할 거라고 만약 내가 궁금하네요

class AItemsController 
    def new 
    end 
end 

class BItemsController 
    def new 
    end 
end 

# view files layout 
> views 
    > AItems 
    > new.html.erb 
    > BItems 
    > new.html.erb 

# routing 
get '/AItems/new' 
get '/BItems/new' 

# code for /views/AItems/new.html.erb 
<%= render "layouts/items_new", object: "AItems" %> 

# code for /views/BItems/new.html.erb 
<%= render "layouts/items_new", object: "BItems" %> 

을 : 이것처럼 모든 것이 중복되어 있습니다. (필자는 아직 DRY를 시도하지 않았습니다.) 다음과 같이 보입니다. (매우 설명하기 만하면 이름 지정 규칙이 거의 없다는 것을 모든 것이 기본적으로 동일하게 보여줍니다.)

class AItemsController 
    def new 
    @items = AItems.joins(:order).where("orders.status_id IS NULL") 
    end 

    def do_something 
    a_items_params.each do |item_params| 
     key_var = item_params[:some_attribute] 
     ... 
    end 
    end 
end 

class BItemsController 
    def new 
    @items = BItems.joins(:order).where("orders.status_id IS NULL") 
    end 

    def do_something 
    b_items_params.each do |item_params| 
     key_var = item_params[:some_attribute] 
     ... 
    end 
    end 
end 

나는이 점에 대해 아직 논란이있어. 아래의 예는 예시이며, 코드가 정확하지 않을 경우 용서하지만, 바라기는 요지를 얻습니다.

솔루션 A : 하나의 방법으로, 나는 각 컨트롤러에서 작업 정의를 유지할 수하고 공유 문제에서 작업 풀 내에서 코드가 있습니다

class AItemsController 
    include SharedCode 

    def new 
    shared_new 
    end 

    def do_something 
    shared_do_something 
    end 
end 

솔루션 B를 : 추상적 인

class AItemsController 
    included SharedAction 

    shared_action("AItems") 
end 

솔루션 C : 단수 컨트롤러 경로의 모든 것을 공유 우려 떨어져 활동 정의 다시 (보기에서 전달) 구별하기 PARAMS를 사용

class ItemsController 
    def new 
    item_type = params[:item_type] 
    end 

    def do_something 
    item_type = params[:item_type] 
    end 
end 

모델 코드

이 사람은 조금 더 잘라 내기 및 건조, 나는 여기에 피드백의 톤을, 내가 할 필요가 없습니다 주요 메소드/콜백에 대한 공통 관심사를 사용했습니다.


분명히 하나에 대한 대답은 다른 것에 영향을 미칩니다. 예를 들어, 모든 것이 단일 컨트롤러를 통해 라우트되는 경우 부분 접근이 아닌 매개 변수가있는 단일 뷰를 갖게됩니다. 그러나 컨트롤러에는 여러 가지 DRY 옵션이 있으므로 논쟁의 여지가 여전히 있습니다.

당신이 지금까지 읽은 적이 있다면, 나는이 질문이 당신이 무엇을 할 것인지에 대한 최소한의 생각으로 너무 느슨하게 정의 된 방법에 대해 화를 잘 낼 것이다. 내 코드를 인계 받았다면 더 이해할 수 있을까요?

나는 배우려고 노력하고 있으며,이를 수행하는 가장 좋은 방법은 다양한 관점과 장단점을 요구하는 것입니다.

+1

아마도 상속을 사용할 수 있지만 항목 테이블을 사용하지 않고 A 항목과 B 항목에 대한 태그 만 사용하는 이유는 무엇입니까? – MageeWorld

+1

위와 (단일 테이블 상속) 동의합니다. 그러나 또 다른 옵션이 있습니다 : ItemsController를 서브 클래 싱하십시오. 예를 들어 Solution C를 사용하지만, AItemsController

+0

MageeWorld 코드 이유가 아닌 분리 된 비즈니스 이유입니다. 그것은 우리 회계를 훨씬 더 빠르고 쉽게 만듭니다. TarynEast 나는 그 생각, 좋은 제안을 좋아한다! – james

답변

0

체크 아웃 InheritedResources 보석는 : https://github.com/josevalim/inherited_resources

상속 된 자료는 단지 중요한 무엇에 집중해야하므로 모든 편안한 작업을 당신의 컨트롤러를 상속함으로써 개발 속도가 빨라집니다. 같은 시간에 에서 컨트롤러를보다 강력하고 깨끗하게 만듭니다.

또는 응답자 보석, 상속 된 자원에 대한 대체 : 응답자 모듈의 https://github.com/plataformatec/responders

세트는 4.2 응용 프로그램 레일즈를 건조.