Decorator と Presenter を使い分けて、 Rails を ViewModel ですっきりさせよう - KitchHike Tech Blog
はじめに こんにちは。KitchHikeエンジニアの小川です。 Webアプリケーション開発において、コードベースが大きくなってくると、よく問題になるものの一つが表示ロジックの重複ではないでしょうか。知らず知らずのうちにビューに同じようなロジックが増えて、コードの見通しが悪くなってくるのです。 KitchHikeのコードにもその兆候が見られはじめたので、対策として ViewModel パターンを取り入れています。このパターンを適用することで、表示ロジックを集約し、コードのメンテナンス性を向上させることができました。 ViewModel は、そんなに凝ったことをしているわけではないのですが、コードをすっきりさせる上ではかなり強力なパターンです。 今回はこの ViewModel について、実際の使い方を含めご紹介したいと思います。 ViewModelとは? 一言でいえばビューに関連するロジックを
Why Factories?
These days, most Rails projects use some form of factories in their test set up. What problem do they solve and why are they needed? Too much info Given a User model with first_name, last_name, and location fields, we could write a test like: describe "#full_name" do it "combines first and last name" do user = User.new( first_name: "Joël", last_name: "Quenneville", location: "Boston" ) expect(user
みんなRailsのSTIを誤解してないか!? - Qiita
な、なるほど...!? いや、みんなちょっと誤解してるんじゃないか? よーし、お父さん、みんながSTIを使いたくなるようにちょっと頑張っちゃうぞ! STIとは STIは、単一の継承階層に所属するクラス群を、ただひとつのテーブルを使って永続化する手法です。 PofEAA Railsのドキュメントを漁ると、次のような記述が見つかります。 http://api.rubyonrails.org/classes/ActiveRecord/Inheritance.html Note, all the attributes for all the cases are kept in the same table. Read more: www.martinfowler.com/eaaCatalog/singleTableInheritance.html このリンク先は、リファクタリングで有名なMarti
Railsで大規模アプリケーションを正しく設計するために避けるべき3つの機能 - Qiita
この記事はCrowdWorks Advent Calendar 2016 の24日目の記事です。CrowdWorksのエンジニアが毎日なにかを書きます。 昨日の記事は @suzan2go による「ラーメン屋で考えるRailsのデータモデリング」でした。 はじめに CrowdWorksは、2011年の創業以来、約5年間の開発を続けてきました。サービスの立ち上げ期においては、サービスの継続性・変更容易性を高めることよりも、サービスを成長させ、存続に繋がるフェースまで素早く立ち上げることが最重要な観点です。 一方で、サービス提供も5年が経過し、多くの方にご利用頂く「社会インフラ」に一歩ずつ近づいてきています。そういった環境の変化もあり、「日々改善し続ける」「日々変更し続ける」ことに重要視する観点が移り変わってきました。そのような価値観の変遷に取り組む過程で考えている「大規模で複雑な業務要件を担う
Railsを事例にして学ぶ、むやみにモジュール分割しているとハマる落とし穴とその回避策 - Qiita
この記事は リクルートライフスタイル Advent Calendar 2016 5日目の記事です。 ビューティー開発Tの@tacuma_igeiです。主にRailsを使って、まだここにない出会いを創出していこうと励んでいます。 はじめに 中規模〜大規模のRails開発をする上で、多くの人が直面するであろう「ApplicationController・Helper散らかる問題」に対して、多くの人がやりがちな対処法とその落とし穴について理解を深め、回避策を提示していければと思います。 需要がありそうなので 事例をRailsにしていますが、基本的にRubyの話なので、Sinatra や Padrinoでも同様の問題が起こりえます。 結論 結論から述べると、 モジュールに切り出してMix-inする場合は、module_functionを使って、明示的にモジュール関数を呼び出すようにしましょう 時間
俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは止めてくれ - Qiita
class HogehogeService # Hogehogeはモデル名まんま def process(hogehoge, option_a: nil, option_b: nil, option_c: false) history = hogehoge.histories.last unless hogehoge.active? hogehoge.histories.last.update(state: :cancel) return error_message end case hogehoge.kind when "type_a" # ... when "type_b" # ... end ActiveRecord::Base.transaction do history.save! history.create_foobars end end end 何が酷いって、機能が何なのか
Railsにおけるサービス層の導入と感触 - Qiita
http://qiita.com/kbaba1001/items/e265ad1e40f238931468 で Rails のアーキテクチャを改善する話を書きましたが、理屈っぽい話になっていたので、今回は具体例として実際に私が仕事で実践していることについて書きます。 半年ほどサービス層を作りまくっていますが、最高としか言いようがありません。 Modelとロジックが切り離されているので、本番運用をはじめた後もかなり柔軟に開発を続けられています。 (さすがにERに影響がある変更には手を焼きますが...) サービス層を作って Fat Model 対策をすることは Rails 開発において有効な設計だと感じています。 Rails にサービス層を導入する最も簡単でパワフルな手段は Trailblazer を使うことです。 しかし、本記事では Reform を使ってサービス層を自作する方法について書き
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GenStage Under Umbrella?
似非サービスクラスの殺し方 / #ginzarb
中／大規模開発のためのRails設計パターン - Qiita