Rails
りんだRailsの基本思想（by DHH）
- DRY
- 設定より規約を優先する
- Railsの定める規約を守ることで、Webアプリケーション開発においてほぼ必ず通るであろう、設計・実装上の瑣末な項目に関して、考えたり議論したりするコストが減る
- メニューは”おまかせ”で
- 基本的にはRailsの作ったツール群をそのまま使うことで、既に洗練されているツールの恩恵を受けることができる
- どうしてもユースケースに合わない場合は独自でも全然OK
- パラダイムが1つではない
- Railsは多くの異なる考え方やパラダイムから構成されている
- ほとんどの個々のパラダイムは、ある問題の特定の空間でよく機能するが、それ以降のちょうどよい範囲を超えて適用される場合は、厄介なもの、あるいは柔軟性のないものになる
- 多くのパラダイムを組み合わせることで、守備範囲広く問題に対応できる
- 美しいコードを称える
- コードが美しいと開発者が気持ちいいので追求しよう、みたいな話
- ここでいう美しさとは、行数が少なく、カードの見た目がシンプルな状態を指していると思われる
- これがたぶん別の見方をすると「Railsは機能を隠蔽しがち」と言われる所以なんだろうなと思う
- 統合システムを尊重する
- フロント・バック・インフラ、その辺の領域を一気通貫で扱っており、そのシステムを尊重する
- 安定性より進歩を重視する
- 今使ってくれてる人の慣れに配慮するのも大事だけど、システムの進歩の方が大事
- テントを押し上げる
- Railsを使う人・作る人に関して、来る人拒まず、参入のハードルを低くする
- たとえばDHH個人は、Railsをビュー部分を含めたフレームワークとして推すことに尚注目し続けているが、一方でAPIとしてフロントと独立した使われ方をする、というのもアリだし、その用途でも役立つ余地は必ずあると思っている。
りんだmodel層の責務
- データベースの操作およびビジネスロジックを記述する。
controller層の責務
- 入力値のバリデーション
- 入力値を適切なビジネスロジックへ委譲
- 適切な出力形式を選択してoutput rendererに処理を委譲
りんだSTI
STI(Single Table Inheritance)は単一テーブル継承。
Railsでデフォでサポートされていて、一つのテーブルに複数のモデルを扱う感じ。ここでのモデルは擬似的なテーブルと粒度が同じになる。たとえば、UserとCampanyというモデルを、Customerという一つのテーブルで一緒くたに管理する。Railsではtypeというカラムを使って、どの種類のデータ（モデル）なのかを判断する。
よくわかんないけど、この手法を敬遠する記事は多かった。上でいうとUser用のカラムを設けたとして、Customer側の全データでそこはNULLになってしまう。これが擬似テーブルの数も増え、カラムの数も増え、となると、テーブルにNULLが溢れるためよくない（そもそもなぜテーブルにNULLが入ることが良くないのかはまだ知らない）。
りんだCTI
CTI(Class Table Inheritance)はクラステーブル継承。
抽象クラスも、具象のクラスも、すべてテーブルを作成する。STIの例でいうと、CustomerもUserもCumpanyも全部テーブルとして存在する。
抽象クラスのテーブルでは、STIと同じくtypeというカラムで、どの種類（モデル）のデータかを表現する。具象クラスのテーブルでは、抽象側にはないそのテーブルだけが必要なカラムを設け、また、親_idみたいな名前のカラムで抽象側とのつながりを表現する。
よくわかんないけど、基本的にSTIよりもこっちの方がネットで推されていた。それは直感性や、STIがNULL許容的なつくりだから、だと思われる。
個人的にも、過度なDRYは好きでないので、CTIの方が好きかも。
りんだCTIを選んだ場合はdelegeteを使うとよい
Userが具象クラス、Customerが抽象クラスだとして、Customerが持ってるモデルやメソッドにアクセスしたいときに、user.customer.hogehogeとなるのは読んでてどゆこと？を少し生みやすくなり、若干可読性を下げる。
なので、こういう感じでdelegateを使って、hogehogeにアクセスしたいときはcustomerを省略できるようにしておくのがよい。
delegate :hogehoge, to: :customer
りんだむやみにservice使うのはやめよう記事。中身みたけどぜんぜんわからなかった。
りんだマストドンのリポジトリ。サービスクラス、エラーハンドリングなどが参考になるらしい。