contentみんたくみんたくの技術ブログHome開発技術RailsRails開発からMVCアーキテクチャを考える2019年7月12日TwitterFacebookはてブPocketLINEFeedlyフィードRails開発からMVCアーキテクチャについて考えてみました。各レイヤにおける構成と役割を整理することで、より良い開発を目指していきたいです。M(モデル)・V(ビュー)・C(コントローラ)Railsは一般的なフレームワークと同様、MVCアーキテクチャ(構造)となっています。Model(モデル)View(ビュー)Controller(コントローラー)MVCそれぞれ役割分担されていることで、効率的に開発することができます。各レイヤは以下のように対応されます。ModelRailsによるアプリケーション開発ではMVCアーキテクチャを意識しないと、規模が大きく開発期間が長くなるにつれ複雑怪奇なものになっていきます。複雑な機能や機能数を増やしていくとControllerでロジックや処理が集中しコード量が増え、仕様変更や保守・運用が大変になります。そのためにも今一度MVCアーキテクチャを整理し、理解したうえで開発に取り組むことが大事だと考えます。Rails開発から各レイヤのアーキテクチャを整理する■ユーザインタフェース層views・app/viewsviewテンプレートファイルが置かれ、HTMLをレンダリングします。view_objects・app/view_objectsViewで使用するデータオブジェクトです。Modelを使いやすいよう整形し、Viewで表示する橋渡し的な役割です。■アプリケーション層controllers・app/controllersユーザからのリクエストを受け、ドメイン層に対して命令をします。ビジネスロジックはできるだけ記述せず、セッション管理やHTTPリクエスト・レスポンス処理などを担当します。クラス名の命名規則として、末尾にControllerを追記します。Hoge.allendenddecorators・app/decoratorsモデルからビューへ表示するためのロジックやデータ整形はdecoratorsに書きますhelpersでも良いですが、グローバルメソッドであるため、すべてファイルから呼び出せてしまうのが難点。一応対策として、以下でHelperがすべてのViewから読み込むのを防ぐことができます。modelではリレーションやenumなどデータ管理を行います。Controllerからの命令に従ってデータを用意します。}endservices・app/servicesドメイン層における複雑なロジックをここに書きます。登録・更新や絞り込み検索、計算など、複雑な機能では自然とservicesのコード量が増えていきますね。queries・app/queriesmodelのクラスメソッドやscopeを記述します。使ってなかったですが、DBに対して操作するクラスメソッドやscopeの記述はこちらに書くが正しいようです。value)}endvalidators・app/validatorsカスタムバリデーションを追加する場合は、ここに書きます。ActiveModel::EachValidatorを継承し、validate_eachメソッドを実装します。modelsのバリデーション機能をvalidatorsに切り出すことで、modelがfatになるのを防ぎます。:dateend以上のような各レイヤにおけるアーキテクチャについて考え整理し、それぞれの役割を理解した上で開発することが大事だと実感しています。他にもユーザが入力したデータを変換するparametersやデータオブジェクトを管理するview_objectsなどがあり、開発状況に合わせて使い合わせていきたいです。コメントをキャンセルメールアドレスが公開されることはありません。コメントデータの処理方法の詳細はこちらをご覧ください。