레일 모델, 뷰, 컨트롤러 및 도우미: 무엇이 가능합니까?

레일 모델, 뷰, 컨트롤러 및 도우미: 무엇이 가능합니까?

Ruby on Rails Development(또는 일반적으로 MVC)에서 로직을 어디에 배치해야 하는지에 대한 빠른 규칙을 따라야 합니다.

긍정적인 대답을 해주세요 - 여기에 두지 말고, 여기에 두겠습니다.

MVC

컨트롤러:여기에 사용자가 원하는 것을 파악하고, 무엇을 제공할지 결정하고, 로그인했는지 여부, 특정 데이터를 봐야 하는지 여부 등과 관련된 코드를 입력합니다.마지막으로 컨트롤러는 요청을 살펴보고 표시할 데이터(모델)와 렌더링할 뷰를 결정합니다.만약 당신이 코드가 컨트롤러에 들어가야 하는지에 대해 의문이 있다면, 그것은 아마도 그렇지 않을 것입니다.컨트롤러를 마른 상태로 유지합니다.

보기: 보기에는 데이터(모델)를 표시하기 위한 최소 코드만 포함되어야 하며, 대량의 처리나 계산을 수행해서는 안 되며, 모델에 의해 계산(또는 요약)되거나 컨트롤러에서 생성된 데이터를 표시해야 합니다.View에서 모델 또는 컨트롤러에서 수행할 수 없는 처리를 수행해야 하는 경우 도우미에 코드를 입력합니다.보기에 많은 루비 코드가 있으면 페이지 마크업을 읽기 어렵게 만듭니다.

모델: 데이터와 관련된 모든 코드(예: 사이트를 구성하는 엔티티)가 모델에 있어야 합니다.사용자, 게시물, 계정, 친구 등)이 있습니다.코드가 엔티티와 관련된 데이터를 저장, 업데이트 또는 요약해야 하는 경우 여기에 코드를 저장합니다.보기 및 컨트롤러에서 다시 사용할 수 있습니다.

폴리포니의 대답에 덧붙이자면:

도우미: 보기를 더 쉽게 만들 수 있는 기능입니다.예를 들어, 위젯 목록에서 가격을 표시하기 위해 항상 반복적으로 위젯 목록을 표시하는 경우 실제 디스플레이의 일부와 함께 해당 위젯을 도우미에 넣습니다.또는 시야를 어지럽히고 싶지 않은 RJS 조각이 있다면 도우미에게 넣으십시오.

MVC 패턴은 실제로 UI와 관련이 있을 뿐 다른 것은 없습니다.컨트롤러는 보기를 제어하지만 논리는 제어하지 않으므로 복잡한 비즈니스 논리를 컨트롤러에 배치해서는 안 됩니다.컨트롤러는 적절한 보기를 선택하고 도메인 모델(모델) 또는 비즈니스 계층에 더 복잡한 항목을 위임해야 합니다.

도메인 기반 설계에는 논리를 고정하는 여러 가지 유형의 객체를 조정해야 하는 서비스 개념이 있으며, 일반적으로 모델 클래스에 속하지 않는 논리를 의미합니다.

저는 일반적으로 서비스 계층을 애플리케이션의 API로 생각합니다.내 서비스 계층은 일반적으로 내가 생성하는 애플리케이션의 요구 사항과 매우 유사하므로, 서비스 계층은 내 애플리케이션의 하위 레벨에서 볼 수 있는 보다 복잡한 상호 작용을 단순화하는 역할을 합니다. 즉, 서비스 계층을 우회하여 동일한 목표를 달성할 수 있지만 이를 실현하려면 훨씬 더 많은 수단을 사용해야 합니다.

여기서 제가 말하는 것은 레일즈에 대한 것이 아닙니다. 저는 특정 문제를 해결하는 일반적인 건축 스타일을 말하는 것입니다.

여기서 이미 완벽한 설명, 결론적으로 매우 단순한 문장 하나, 기억하기 쉬운 문장 하나:

우리는 SMART 모델, THIN 컨트롤러, DUMB 뷰가 필요합니다.

http://c2.com/cgi/wiki?ModelViewController

레일즈의 방법은 마른 컨트롤러와 뚱뚱한 모델을 갖는 것입니다.

컨트롤러에 권한 부여/액세스 제어와 관련된 내용을 넣으십시오.

모형은 데이터에 대한 모든 것입니다.검증, 관계, CRUD, 비즈니스 로직

보기는 데이터를 표시하는 것입니다.표시 및 입력만 받습니다.

컨트롤러는 모델에서 뷰(및 뷰)로 이동하는 데이터와 뷰에서 모델로 이동하는 데이터를 제어하는 것입니다.컨트롤러는 모델 없이도 존재할 수 있습니다.

저는 컨트롤러를 고객(요청자)을 창구 직원(보기)에게 질문하는 적절한 카운터로 안내하는 보안 요원/접수 담당자로 생각하고 싶습니다.그런 다음 창구 직원(뷰)이 가서 당신이 결코 보지 못하는 관리자(모델)로부터 답을 얻습니다.그런 다음 이 요청은 보안 요원/접수 담당자(컨트롤러)에게 돌아가서 다른 직원의 질문에 대해 매니저(모델)가 알려준 답을 알려주는 다른 직원(뷰)에게 전달될 때까지 기다립니다.

마찬가지로, 만약 당신이 창구 직원에게 무언가를 말하고 싶다면, 두 번째 창구 직원이 당신의 정보를 받아들였는지 여부를 알려주는 것을 제외하고는 거의 같은 일이 일어납니다.또한 관리자에게 그 정보를 말할 권한이 없으므로 보안 요원/접수 담당자(컨트롤러)가 당신에게 하이킹을 가라고 했을 수도 있습니다.

그래서 은유를 확장하자면, 틀에 박힌 비현실적인 나의 세계에서 텔러(관점)는 예쁘지만 머리가 텅 비고 종종 당신이 그들에게 말하는 것을 믿습니다.경비원/경찰관은 최소한의 예의를 갖추지만 그다지 지식은 없지만 사람들이 가야 할 곳과 가야 하지 말아야 할 곳을 알고 있으며 관리자들은 정말 못생기고 비열하지만 모든 것을 알고 있으며 무엇이 진실이고 무엇이 아닌지를 말할 수 있습니다.

적절하게 분리하는 데 도움이 되는 한 가지 방법은 "컨트롤러에서 보기로 로컬 변수 전달" 안티패턴을 피하는 것입니다.이 대신:

# app/controllers/foos_controller.rb:
class FoosController < ApplicationController

  def show
    @foo = Foo.find(...)
  end

end

#app/views/foos/show.html.erb:
...
<%= @foo.bar %>
...

도우미 방법으로 사용할 수 있는 게터로 이동해 보십시오.

# app/controllers/foos_controller.rb:
class FoosController < ApplicationController

  helper_method :foo

  def show
  end

  protected

  def foo
    @foo ||= Foo.find(...)
  end

end

#app/views/foos/show.html.erb:
...
<%= foo.bar %>
...

이를 통해 "@foo"에 무엇을 넣는지, 어떻게 사용하는지 더 쉽게 수정할 수 있습니다.컨트롤러와 보기를 더 복잡하게 만들지 않고 분리할 수 있습니다.

음, 그건 논리가 무엇을 다루느냐에 달려있어요...

종종 모델에 더 많은 것을 적용하여 컨트롤러를 작게 만드는 것이 합리적입니다.이를 통해 모델이 나타내는 데이터에 액세스하기 위해 필요한 모든 장소에서 이 논리를 쉽게 사용할 수 있습니다.보기에는 논리가 거의 포함되지 않아야 합니다.그래서 정말로, 일반적으로, 여러분은 반복하지 않기 위해 그것을 만들기 위해 노력해야 합니다.

또한, 구글의 짧은 부분은 무엇이 어디로 가는지에 대한 몇 가지 더 구체적인 예를 보여줍니다.

모델: 검증 요구 사항, 데이터 관계, 메소드 생성, 메소드 업데이트, 메소드 파괴, 메소드 찾기(이러한 메소드의 일반 버전뿐만 아니라 성으로 빨간 머리를 가진 사람을 찾는 것과 같이 많이 하고 있는 것이 있다면,그런 다음 논리를 추출하여 find_red를 호출하기만 하면 됩니다.H_by_name("스미스") 또는 그와 비슷한 것)

보기: 이것은 데이터의 처리가 아니라 데이터의 형식에 관한 것이어야 합니다.

컨트롤러:여기서 데이터 처리가 이루어집니다.인터넷에서: "컨트롤러의 목적은 사용자가 요청한 작업에 응답하고, 사용자가 설정한 매개 변수를 가져와 데이터를 처리하고, 모델과 상호 작용한 다음, 요청한 데이터를 최종 형태로 뷰에 전달하는 것입니다."

도움이 되길 바랍니다.

간단히 말하면, 일반적으로 모델은 테이블과 관련된 모든 코드, 단순하거나 복잡한 관계(여러 테이블을 포함하는 SQL 쿼리로 간주), 비즈니스 로직을 사용하여 결과를 도출하기 위한 데이터/변수 조작을 포함합니다.

컨트롤러는 요청된 작업과 관련된 모델에 대한 코드/포인터를 갖게 됩니다.

보기는 사용자 입력/상호 작용을 수락하고 결과 응답을 표시합니다.

이러한 부분에서 크게 벗어나면 해당 부분에 불필요한 부담이 가해져 전체 애플리케이션 성능에 영향을 미칠 수 있습니다.

테스트, 테스트...모델에 가능한 한 많은 논리를 넣으면 제대로 테스트할 수 있습니다.단위 검정은 모델을 테스트하여 데이터와 데이터가 형성되는 방식을 테스트하고, 기능 검정은 컨트롤러를 테스트하여 라우팅되거나 제어되는 방식을 테스트하므로 데이터가 모델에 있지 않으면 데이터의 무결성을 테스트할 수 없습니다.

j

언급URL : https://stackoverflow.com/questions/60658/rails-model-view-controller-and-helper-what-goes-where