MVPとCellsを利用してプログラムコードを整理します

今回のrubyconfでは、プログラムコードを整理するテクニックで、MVPとCellsの2つの比較的少ないテクニックを紹介しました.
MVP ? どうやってMVCに似てるの?彼らには何か関係がありますか?
そう、MVPは実はModel-View-Presenterの略です.
MVPとは
一般的な実作MVCアーキテクチャでは、

「ビジネスロジックに関する資料」および「資料の処理方法」をカプセル化するには、Model

に置かなければならない.

からViewまで、「資料とインターフェースの提示を担当する」

のみを担当する.
しかし、あなたも私もよく知っています.これは「理想の状態」です.
実際の状況は、

多くのウェブサイト「UI高度依存ビジネスロジック」

ビジネスは非常に複雑で、controllerまたはviewでビジネスロジック

を実行せざるを得ない場合があります.

実務的には複雑なmethod refactorをmodelに移すことを教えてくれますが.しかし、現実的にはmethodでこのViewで一度だけ使用する業務もある.そしてモデルにあるべき基礎methodではありません.何でもモデルに投げつける化で、モデルは異常に肥大してしまいます.

だからMVCのようなアーキテクチャは最後には使用できません.最後にPresenterをさらに実装する必要があります.

は比較的少ないが、実用的な複雑な/expensiveビジネスロジックを抽出してPresenter

に置く必要がある.

ビジネスロジックが抽出されてPresenterに置かれると、UIを変更する難易度は

より低くなります.

    class Sites::ShowPresenter

      def hottest_topics
        @hottest_topics = @site.topics.hottest.limit(10)
      end

      def recent_topics
        @recent_topics = @site.topics.unhidden.recent(10)
      end

    end

    def show
      @presenter = Sites::ShowPresenter.new(@site)
      @headline_topic = @presenter.headline_topic
      @categories =  @presenter.categories
      @site_alias = @presenter.site_alias

      add_breadcrumb @site.name, site_path(@site)
      seo_meta_desc_keywords(@site)
    end

これにより、codeのメンテナンス性が大幅に向上します.
セルとは?
それでもPresenterは足りません.
これもNickが書いたRails Misapprehensions:What the fuck is MVP?一文の主な原因.
(講演会の後、著者のNickさんと少し話をしました.彼のCellsのデザインを褒めました.彼はさっぱりしていて、ついに誰かがCellsのデザインの原因を知っていると思っていました.そして不思議に思っていました.彼の文章ははっきり書いているのに、どうしてたくさんの人が分からないのですか.Cellsはまだ少ない人が使っています.LTを延長してXDを広告してあげましょう)
足りないのは、PresenterでControllerを整理する動作しかできなかったからです.MVPは「大段のプログラムコード」をControllerから搬出するだけ.
本当に解決すべき理由はありません.
「避けられないのはViewsの中で論理を作って、query資料」
どう思う?
Big deal
私はCellsを使い始めます.初心はMVCに厳格に従いたいからではありません.Cacheを必要とするコードが増えているので、今の事件でcacheを必要とするコードを整理するのに良い方法が必要です.
Cellsはcodeを整理する方法が私のニーズに合っているので、私たちは大きなプログラムコードをCellに移してcacheをし始めました.
1ヶ月後、Bad performance codeを整理する時間になりました.
専案のいくつかのプログラムコードは実はとても嫌いで、あなたはどうしてもViewの中で輪query資料に戻らなければなりません.例えば、このようなcode:

  <% sites.each do |site| %>
    <% site.categories.each do |category| %>
      <% category.popular_posts.each do |post| %>
         <%= post.title %>
         <%= post.content %>
      <% end %>
    <% end %>
  <% end %>

このコードはとても痛いです.Developerはこのcodeにはほとんど方法がありません.
君にできることはただ残っているから

全体にcacheを打って、背景preheat cache

にあります.

partialに分解して階層ごとにcacheを打つ.背景preheat cache

controller/presenterでincludesを降りてjoinになってquery数を減らします.

OK.これは実は何の役にも立たない.スピードがあまり速くないからだ.
これはperformance issueを後ろに引きずって解決しただけだ.
スピードの遅い真の元凶
本当にスピードが遅い元凶は、Query in Viewです.
Rails Developerはすべて知っていて、partialはとても遅いです.しかし、その原因を究明する人は少なく、問題をRailsのせいにしているだけだ.
しかし、実際に真剣に追いかけてみると、htmlを純粋に入れたviewが見つかり、renderはとても速いです.
本当に遅いのは、Viewで資料/query資料を処理しなければならないpartialです.
ULTRA SLOW
勝手に中にあるものをqueryします.partial全体が死ぬほど遅い.
さらに悪いことに、もしあなたのHeaderのリストがQuery資料が必要なら、おめでとうございます.大当たり!
どうやって解くの?
Controllerに引っ越してquery羅へ!
でも前の段のcodeは、全然運べないよ...
Cellsが提供する解決方法
Cellsの動作原理は,各セグメントにcacheを必要とするcodeを1セグメントcomponentにすることである.このcomponentには自分の「mini controller」と「view」がある.
Cellsのメカニズムにより,viewではなくheavy queryをmini-controllerに大幅に取り外すことができる.
これはプログラム潔癖者の中毒を解消しただけでなく(MVCでコードを入れなかった)、実は深刻なperformance issueを解決した.
前のcodeのように、実は私はそれを3層cellに分解することができます.
このようなテクニックを使って、Cellを使って汚いプログラムコードを書き直すことに成功しました.運行時間は550 msから10 msに大幅に下がった.君が信じようと信じまいと、ぼくはどうせ信じたんだ.
Cellsの背後にある物語
Cellsの背後にある理屈が実は二重のissue(MVCとquery in view’s performance issue)を解いたと思うと、このようなすごいデザインに心から感嘆しました.何日も興奮した.
今回Rubyconf、私は特に作者のNickにこのような考えかどうかを闻いて、彼はとても喜んで1つの知音に出会って、そして私に多くの人がCellsを使わないと愚痴をこぼして、彼をとてもうっとうしいです...明らかに彼はCellsとPresenterの说明を书くのがとても简単で、やはり多くの人が理解できません..
それから彼がとっくに書いた投影映画を取り出して、私と私の家のSA vincentにLT XDDDDDを手伝うように強要しました.
その后、私は彼に闻いて、どのようにこのようなIdeaを思い出します.彼は言います:“私はルビーを使って2時間、更にRailsを使って2時間、それからこのような愚かなMVCに耐えられなくて、自分で1セットしました......”
締めくくり
もしあなたがPerformanceのissueを持っているなら、Railsを責めないで、まずあなたのpartialがこのような設計を取っているかどうかを見てみましょう.Cellsはcacheを整理する良いツールだけでなく、Codeを整理する絶好のツールです.あなたのcodeがもっとMVCになるのを助けて、走るのがもっと効率的です.
広告:Essential Rails Design Pattern for Beginnersという本は、即日前売りを開始します.原価14.99 USD.前売りは9.99です.この本は9月末か10月初めに出版される.
本章「MVPとCellsであなたのプログラムコードを整理する」も収録される.