中規模Web開発のためのMVC分割とレイヤアーキテクチャ - Qiita
TL;DR MVCもレイヤで捉えて関係性の設計をするといいのでは 普通のRubyオブジェクトを積極的に使いたいですね 「パーフェクト Rails」に期待しましょう 長くなって面倒くさくなり、途中から手抜き感が半端ないですが許してください この記事の位置付けなど 7 Patterns to Refactor Fat ActiveRecord Models - Code Climate Blog [翻訳] エリック・エヴァンスのドメイン駆動設計 エンタープライズ アプリケーションアーキテクチャパターン これらの参考文献を踏まえてRailsアプリケーションのリファクタリングをしていて、だいぶ方向性や考え方がまとまってきたので、これからチームに合流する人を想定読者に、Qiitaがどんな感じで作られているのかを文書化したものです。（参考文献の一覧は記事の最後にあります） 内容的には文献[2,3]を踏
MVCにおけるcontrollerクラスの役割は時代と共に変わって行く | F's Garage
昔、JavaのフレームワークであるStrutsも出てくる前、MVCモデルにおけるControllerの役割というのは、 「ロジックもデータも見ない現場監督のような役割」 と学んだ。だから昔、ServletではMVCアーキテクチャを学んだ時に、こんなControllerを書いていた。 [とりあえずRequestオブジェクトを受け取る] | [validationロジックに引き渡す。データの中身は見ない] ｜ [例外が発生したらエラーView処理クラスに引き渡す。何のエラーかは細かく知らない] ｜ [次にロジック処理クラスに渡す。最終的にDBのテーブルとマッピングしたデータはJavaBeansというデータクラスが保持する] ｜ [例外が発生したらエラーView処理クラスに引き渡す。何のエラーかは細かく知らない] ｜ [Viewの生成オブジェクトにJavaBeansを渡す] ｜ [Viewオブジ
Webアプリケーションのサービスクラスとは何か - 虎塚
「JSP、サーブレット、サービス、DAO、DTOといった構成のアプリケーションにおけるサービスクラスとは何か」、という問いに自分なりの答えを出すのが、今日の宿題です。 自分の解答 ※注意: 以下の文章は言い切り形式で書いていますが、間違っているかもしれません。 ちょろっと調べたのですが、サービスについてそのものズバリの単一な定義を見つけることはできませんでした。なので、いくつかの観点から理解することを試みます。 モデル、ビュー、コントローラにおける「サービス」 アプリケーションをモデル、ビュー、コントローラに分けて見たとき、サービスはモデルに属します。モデルには、データベースアクセスを行うクラスと、システム固有の処理を行うクラスがあります。 サービスは、後者のシステム固有の処理を行うクラスに当たります。 なお、データベースアクセスを行うクラスは、データを保持するクラスと、データベースアクセ
Rails のモデルはどうあるべきか - tomykaira makes love with codes
2013-07-05 Rails のモデルはどうあるべきか rails TL;DR: Rails の model が太りやすいのは、生まれつき責務過剰だから。開発者が設計段階で責務を絞り、食べる量を減らしてあげよう。 Rails の model というのは、概念も実装も、とても奇妙な使われ方をしている。 いささか不気味だし、実害もある。 fat model はずっと Rails 界で話題になりつづけている。 すでに Rails のプロフェッショナルは抜け出せているのかもしれないが、まだ議論の余地のある話題ではあるようだ。 なぜ model が太るかというと、なんでもかんでも model に食べさせるからである。 一日中食べてれば元々どんなにスレンダーでも太るに決まってる。 コードのダイエットは食べる量を減らすか、外に出すしかない。 太ってから外に出すのがリファクタリングである。 後知恵的に
疎結合と MVC と JSON API とオーバーヘッドと非同期とレスポンスタイムに関する適当な考察 - punitan (a.k.a. punytan) のメモ
最近考えていることを話す機会があったので文章にしてまとめてみる。 疎結合 昨今の複雑化するウェブアプリケーションを効率的に開発するにあたって、疎結合な設計にすることは開発／保守効率を上げるためには必須の条件となることは経験上嫌というほど皆が経験している。（このへんの感覚がわからない人は一度疎結合なアプリケーションを書いてみると良い） 疎結合な設計をすることで問題の切り分けが容易になり、自動化されたユニットテスト・コンポーネントテスト・ UAT が手元の MacBook で実行でき、高いカバレッジに助けられて臆すること無くコードに手を入れられる環境を入手でき、開発する上でストレスなく障害も少ないというメリットが享受できる。 話を戻して、疎結合な設計の例をみると、ウェブサーバとアプリケーションを分離することであるとか、 MVC であるとか、良質かつ単体で動く小さなモジュールを組み合わせて書くと
JavaScript MVCフレームワークはすでに十種類以上、その比較や最新情報などのまとめ
グーグルが開発したJavaScript MVCフレームワーク「AngularJS」を紹介した1つ前の記事の反応が予想以上に大きく、1日たたずにブックマークが500以上もつきました。 本記事では、AngularJS以外にもすでにたくさん存在するJavaScript MVCフレームワークに関する情報をまとめて紹介したいと思います。 JavaScript MVCフレームワークの比較記事 既存のJavaScript MVCフレームワークを比較した記事が「The Top 10 Javascript MVC Frameworks Reviewed」です。Top10と書いてありますが、12種類のフレームワークの比較です。これは公開当時は10種類だったものが、その後11種類になり、今回のAngularJSの公開で12種類になったためです。 上記のような比較表を載せた上で、12種類すべての利点と欠点を説明し
「RESTful MVC」なアーキテクチャの話
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）
O/Rマッピング技術の進化が皮肉にも助長している「えせMVC症候群」
昨日の「Ruby on Railsの『えせMVC』の弊害」というエントリー。若干「釣り」の要素が含まれたタイトルが功を奏したのか、たくさんのフィードバックがいただけた。そんな中で見えて来たのは、この問題はRailsに限った話ではなく、業務用アプリケーションで使われているJavaや.Netの世界でもよく見られる問題だということ。 その「問題」とは、ActiveRecordに代表されるO/Rマッピングの技術の進化が、本来のMVC（そしてオブジェクト指向そのもの）のメリットを無視した「えせMVC」な設計を助長している、という問題である。 ・MVCやオブジェクト指向を表面的にしか理解していないエンジニアが増えている（ここが根本的な問題） ↓ ・SQLを自分で記述しなくて良いO/Rマッピングはとても魅力的（これはこれで別の問題を含んでいるが、このエントリーではあえて突っ込まない） ↓ ・O/Rマッピ
Buckblog: Skinny Controller, Fat Model
18 October 2006 — The "Fat Controller" anti-pattern is shown and dissected, and the reader is taken through the process of refactoring it into a more readable, maintainable, and testable solution — 5-minute read When first getting started with Rails, it is tempting to shove lots of logic in the view. I’ll admit that I was guilty of writing more than one template like the following during my Rails
まつもと直伝 プログラミングのオキテ 第20回 MVCとRuby on Rails：ITpro
Ruby on Railsをはじめとする最近のWebアプリケーション・フレームワークの多くは，MVCと呼ばれるデザイン・パターンを採用しています。今回は，このMVCパターンの「正体」について考えます。 MVCはGUIを備えたプログラムを設計する際の指針となるデザイン・パターン＊1の一つです。「モデル」（Model），「ビュー」（View），「コントローラ」（Controller）という3つの構成要素の頭文字から命名されました。多くのデザイン・パターンはプログラムの一部のみの構成を決めています。しかし，MVCはアプリケーション全体の構成を決めることが多いため，「アーキテクチャ・パターン」と呼ばれることもあります。 MVCは，元々プログラミング言語Smalltalkにおいて，ウインドウ（GUI）を持つアプリケーションを構築する際の指針として誕生しました。 MVCを発明したのは，当時，米Xero
Ruby on Railsは「えせMVC」じゃないよー - このブログは証明できない。
Life is beautifulのこのエントリーは「釣り」でしょ？ no title 先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 ということで、MVCの解説をされています。それは、OK。で、Railsが「えせMVC」だという理由。 ActiveRecordそのものはとても便利なもので全く問題はないのだが、問題はRailsの解説書などでActiveRecordを使って抽象化されたデータベースをModelと読んでいるケースが多く見受けられる点だ。 上に述べた通
Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MVCの先、状態管理、ジェスチャー
GUIアーキテクチャパターンの基礎からMVVMパターンへ
Separate Model from Catalyst
やはりお前らのMVCは間違っている