Trailblazerを使い、Railsのモデルの肥大化問題からサヨナラする - Qiita
はじめに 夏なのに家で冷房を入れることを禁止されているどうも鈴木です。まさに地獄です。 さて、コントーラーやモデルが肥大化する話はRailsを普通に使っていると誰しもが直面する話だと思われます。 例えばUserモデルのように、色々なところから参照されるモデルは地獄みたいなことになってしまいます。地獄は家だけにしてほしいですね。 世間ではサービス層だなんだと言われていますが、何となくapp/servicesなんてディレクトリを作り満足し、後で負の遺産とか言われるのはとても辛いです1。そもそもRails使ってるのはレールに乗るためなので、なるべく賢い人が作ったレールに乗って生きていくのが正義だと思っています2。 ということで、私たちの会社では Trailblazer というgemを使い始めたので、ここで少し紹介します。 もちろん元気よく本番で動いてくれていますよ。 Trailblazerとは？
Railsにおけるサービス層の導入と感触 - Qiita
http://qiita.com/kbaba1001/items/e265ad1e40f238931468 で Rails のアーキテクチャを改善する話を書きましたが、理屈っぽい話になっていたので、今回は具体例として実際に私が仕事で実践していることについて書きます。 半年ほどサービス層を作りまくっていますが、最高としか言いようがありません。 Modelとロジックが切り離されているので、本番運用をはじめた後もかなり柔軟に開発を続けられています。 (さすがにERに影響がある変更には手を焼きますが...) サービス層を作って Fat Model 対策をすることは Rails 開発において有効な設計だと感じています。 Rails にサービス層を導入する最も簡単でパワフルな手段は Trailblazer を使うことです。 しかし、本記事では Reform を使ってサービス層を自作する方法について書き
Rails のアーキテクチャ設計を考える - Qiita
はじめに ここ一年くらいずっと Rails の何がダメでどうすれば良くなるのかを考えていました。 Rails を使ってそれなりの規模のアプリケーションを作ったことがある人なら、メンテナンスのしづらさを感じたことがあるのではないでしょうか。 メンテナンスの問題は Rails 以外の開発でも発生することですが、実のところメンテナンスしやすいアプリケーションはどうすれば作れるのでしょうか？ この難問に対して私も答えを持っていませんが、考え続けています。 少なくとも、 Rails Way や Rails Tutorial をベースにしたアプリケーション開発は、業務で用いるには簡単すぎるように思います。 「レールに乗る」という言葉がありますが、私は考え方を変えました。 Rails は規模の大きいフレームワークですが、土台に過ぎません。 Rails Way の設計方針は小規模な開発では有効ですが、規模
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Trailblazer: Operation Overview
