格納されないものである点も注目です。格納されているものだけではないことを示しています。リソースレイヤーが従来のレイヤーに加わることになります。層とその間を繋ぐプログラム層から成ります。層の間であったインピーダンスミスマッチが、リソース層とプログラム層で発生する可能性があることを示しています。検索結果というリソース、確認画面に対するリソースをどう表現するのかについて悩むことになります。ないことから、その間を繋ぐプログラム層の設計がより重要になってきます。するように実現してはいけません。リクエストをする度にブックマーク数が増えてしまい、べき等ではなくなるからです。更新する」のように実現する必要があります。使ってしまう場合もあります。使用することができます。クライアントが既に知っている場合です。適切なメソッドとなります。メソッドを用いることになります。ついて調べましたが、とても面白かったです。よってもたらされる制約が面白い。ユーザとしてはその効果に期待せずにはいられません。アプリケーションに関わるエンジニアの設計視点が統一されるのも良いことだと思います。原則は非常に良いと感じます。絡めて感じたことは、コントローラ層がリクエストのメソッドを意識しなくてよくなったのがとても良いと思いました。使っていたり、ポストバックによって1つのメソッドに2つの役割を持たせたこともありました。メソッドによってアクションが定まるので、そういった心配はなくなり、コントローラ層がすっきりします。増えるのは若干微妙な気もしますが...。親リソースをロードするためには仕方ないのかなぁ。近いし、あまり好きにはなれない。勉強してさらに良かったのは、設計に対する意識が高まったことです。継承したモデル内に、モデルのレコードを調査してメールを送信するバッチ用メソッドを生やしたりしていました。モデルの仕事はせいぜいバッチ対象となるレコードを取得する部分くらいであって、メール送信はそれこそサービス層でやるのが正しいんだと思います。1テーブルを司るクラスの責任にメール送信があるとは思えません。そんなことを考えながら本を読んでいました。素晴しいフレームワークだなぁと思いました。上杉鷹山を読んだまとめ「先読み力」で人を動かすを読んで。月別アーカイブはてなブログをはじめよう!LukeSilviaさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。