update.はじめにここ数年は仕事でRailsを利用してます。新たにプロジェクトがはじまり、これまでRubyはやっていたけどRailsは初めてという人はあんまりいなくて、RubyもRailsも初めてで、これまではJavaばかりという人がほとんどだったりします。そんな人達に知っておいてほしい基礎知識と実装Tipsを何回かに分けてまとめてみます。次のプロジェクトでメンバーに読んでもらうことも意識しながら第1回は、設計編から。初心者のハマりところ(設計編)■テーブル設計で、ついつい複合主キーを前提にマスタ設計してしまう。IDカラムを物理主キー(サロゲートキー)にしましょう。外部キーも参照するテーブルのIDカラムとしたほうがベターです。複合主キーにすることも可能ですが、Modelのリレーションでいちいちオプション指定をする必要が出てきますし、ActiveRecordの実装も複雑になってくるので、オススメしません。■ページコントローラ型のフレームワーク(JSFなど)に慣れていると、フロントコントローラ型フレームワーク&RESTfulの思想に基づいたRailsの場合、URL設計や画面の粒度・画面遷移で戸惑う。Java歴が長い人の場合は、JSFよりもStrutsの思想に近いという話をすると比較的入りやすいと思います。●RESTfulなアーキテクチャスタイルまたRESTfulについては、GET,POST以外にもPATCH,DELETEといった概念があり、マスタメンテナンスのような画面を例にして、Controllerのアクションメソッドの説明をしていくとよいでしょう。典型的なマスタメンテナンス画面を作る場合、下表のようになると説明するとわかりやすいかと思います。/user/1なお、Rails/RESTfulのスタイルに合わない場合もありますが、その場合は、HTTPメソッドに対して、独自に定義したControllerのメソッドをマッピングします。検索画面を作りたいという場合は、GETを用いて、searchメソッドとマッピングするという形です。URL設計については、下記参考URLの3のSlideShareがわかりやすいです。みたいな画面は作りにくいので、なるべくなら避けるとよいでしょう(バリデーションのメッセージを表示するのもちょっと面倒)。1つの画面に複数の役割の異なるボタンを配置すると、とたんに作りがややこしくなります。APIで受ける形で実装できますが、そうでない場合は1画面で1イベントのようにしたほうがよいです。画面数を節約するためにボリューミーな画面にして、見かけ上の機能数を削減するみたいな思想は捨てて、素直に画面を分割することをオススメします。戯言・・・エンタープライズの世界では、工数削減という名のもとに、機能の一部分が一緒だから、画面を1つにすれば工数削減できると思い込んでいるレガシーな思想がまだ残っていると感じることがあります。upLoginユーザーは見つかりませんでした。