 |
||||||||||||||||
|
||||||||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||||||||
|
||||||||||||||||
| コントローラ（＋サービス）の比較 | ||||||||||||||||
|
次にコントローラの比較をします。前述したようにGrailsのアーキテクチャではサービスクラスも含まれているため、ここでまとめて扱います。 |
||||||||||||||||
| URLとアクションのディスパッチ | ||||||||||||||||
|
URLとコントローラ／アクションのマッピングについては、Railsとまったく同じです。 つまり、コントローラクラスのメソッドが1アクションとして管理されます。そして各コントローラとアクションに対して「/コントローラ名/アクション名」というURLが命名規約により対応します。 |
||||||||||||||||
| ビューへの値受け渡し | ||||||||||||||||
|
Railsではコントローラクラスのフィールドにビューが直接アクセスすることで値のやりとりをします。 Grailsでもまったく同様の方法を利用できます。それに加えてリスト1のようにアクションの戻り値をハッシュにすることでの受け渡しもできます。 リスト1：戻り値によるビューへの値受け渡し
def list = {
|
||||||||||||||||
| Dependency Injection | ||||||||||||||||
|
RailsではDI（Dependency Injection：外部ファイルを用いて生成クラスを実行時に決定させる機構）を取り入れていませんでした。一方、GrailsではSpring Frameworkがうまく統合されています。 以降では、それを具体的に見てみましょう。 リスト2がサービスクラス、リスト3がコントローラクラスです。コントローラに「helloService」という名前のフィールドを宣言することで、自動的に「HelloService」クラスのオブジェクトがDIされます。 リスト2：Grailsのサービスクラス
class HelloService {
リスト3：Grailsのコントローラクラス
class HelloController {
Spring Framework単体で利用した場合のように大量のXMLを記述することはありません。クラス名とフィールド名を命名規約にそって定義すれば、自動的にオブジェクトがDIされます。また、「GRAILS_ROOT/spring/resource.xml」に空のSpring定義ファイルが配置されており、必要に応じてこのファイルを編集することで明示的にDIするオブジェクトを指定することもできます。 |
||||||||||||||||
| トランザクション | ||||||||||||||||
|
Grailsでは「***Service」という命名に従ったクラスを自動的にサービスクラスとみなし、宣言されたすべてのメソッドの開始から終了までをトランザクションに包みます。内部的にはSpring Frameworkのトランザクション機能を利用しているため、必要に応じて上述した定義ファイルを利用すれば、トランザクションの設定を宣言的に指定することもできます。 Railsは宣言的なトランザクションへの対応がなく、ほとんどのアクションをtransactionメソッドで囲まなくてはなりません。この点ではGrailsの方が進んでいるといえるでしょう（Railsのトランザクションの詳細については「第4回：DIコンテナとの比較」を参照）。 |
||||||||||||||||
| コントローラ（＋サービス）比較の結論 | ||||||||||||||||
|
HTTPやビューとのやりとり部分について、GrailsのコントローラはRailsとほとんど同様と考えてよさそうです。 モデルとのやりとり部分については、Javaが持つ強力なトランザクションの機構を簡単に用いられるGrailsに軍配があがるように思います。 |
||||||||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||||||||
|
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
-
-
連載
