How we do MVC – 4 years later · Los Techies
How we do MVC – 4 years later 17 July, 2013. It was a Wednesday. I’ve taken something like a 3 year hiatus from web applications to work mostly on SOA/messaging systems using NServiceBus, and am recently back on an MVC project. Lots of things have changed, but a lot is still the same. Most of what we were trying to do in MVC made it in to the core (strongly-typed views, input/output helpers, metad
MVC で「テーブル：モデル＝１：１」が許されるのは小学生まで - Devel::Bayside
本来、MVC の M はロジックを含み、C はイベントハンドリング、ウェブアプリケーションでいえば、画面遷移のみを担当します。 Catalyst でスキーマローダーをつかって、MyApp::Model::XXXX を自動生成してしまうと、「テーブル：モデル＝１：１」という COBOL 全盛期みたいなアーキテクチャになってしまいます・・。それで、仕方なくロジックを C に書くようにすると、C が見るも無残なほど膨れ上がってしまい、メンテナンスの困難な製品ができあがります（笑）。Rails や Catalyst でも、こういう作り方を推奨している雰囲気があります。 「テーブル：モデル＝１：１」が許されるのは、Rails や Catalyst で本当に小さいアプリケーションを作るときまでで、多少大きいアプリケーションを作ろうと思ったら、MyApp::Model::XXXX を自動生成するなら、M
【雑記】 そろそろMVCモデルについて一言いっておくか
なーんて、MVCを語れるほどの知識はないのだが、琴線に触れてしまったので、私なりに言いたいことを言うことにする。 本当は、こんな話より先に、先日参加したGAE Nightの話や、Winnyの金子さんが無罪になった話を書きたいのだけど、ココとか、ココとか、ココとか、ココとか、毎日毎日毎日毎日、MVCを語られると、何かいいたくて、もう我慢できなくなってしまった。（これはエンジニアの性なのか！？） 中島さんのBlogのなかで最も釣られてしまうキーワードは「えせ」。これを使うということは、自分の考えだけが正しくて、他は間違いであるということを暗にいっているようなもの。多くの人はそれに反応してしまうから、感情論になって、あまりよい結論は見い出せなくなってしまっているんじゃなかろうか。中島さんの言っていることは概ね理解できるし、RESTfulな設計などは私の考えと被る部分もあって、ほぼ同意できるのだが
現場のコード : 最終回 MVCを理解してテスト可能なコードへ | Basuke's Blog
2011年にMOSAのMOSADENコーナーに連載させてもらった「現場のコード」第四回にして最終回です。結局ここが書きたかったというMVCのお話。CocoaのMVCを実践していくために必要な考え方を話しております。 しかし、１年前の今日、2011年の大晦日にドタバタと公開してますな。まったくもってMOSA関係者の皆様には、原稿が遅くて本当にご迷惑をおかけしました。ごめんなさい。連載の機会をいただきありがとうございました。 初出：2011年12月31日 前回からずいぶんと時間が空いてしまいました。前回はテストできるコードの条件について考えたところで、では実際にテストしていくためには、どのようなコードを書いたら良いのか考えていきます。テストできるコードを書く上で何より大事なことは、まずMVCという考え方を身につけて実践していくことだと僕は考えてます。 MVCがテストへの道筋 MVCという考え方
OTN Japan - 今だからデータ・アクセスを真剣に考える！ 第2回
前回の「データベースことはじめ（前編）」では、システムの論理的な階層の中でドメイン層をどの様に実装するかということで、PoEAAのアーキテクチャパターンを元に見てみました。今回は、パーシステンス層のアーキテクチャパターン＋αを見ていきます。 まずパーシステンス層を見る前に、今回の話題とは直接ではないですが、間接的に関わってくる層のサービス層に関して少し触れておきたいと思います。サービス層は、ドメイン層配下のビジネスロジックをユーザインタフェース層やアプリケーション層から利用するためのインタフェースとして機能します。一般的にトランザクションロジックやセキュリティロジック、ドメインロジックのワークフロー等のドメインロジックとは直接関係ないロジックを含むのみで、大きなドメインロジックを含むことは好ましくないとされる層です。 では、パーシステンス層です。ここまで、役割的には、データアクセスの実装を
第14回 DataMapperの使い方 | gihyo.jp
DataMapperのコンポーネントは、基本的にクラスではなくモジュールとして提供されているため、アプリケーションで利用するモデルクラスにインクルードして使います。 Resourceモジュールをインクルードすると、自動的にModelモジュールがextendされ、PersonクラスはModelクラスとして振る舞うようになります。これは図1のPersonに相当します。 図1のPerson Mapperに相当する仕組みはRepositoryです。Repositoryは、create, update, delete, read_one, read_manyなどの、データストアに対する基本的な操作のインターフェイスを規定します。Modelクラスは、Repositoryへの参照を持っていて、 Modelクラスによるデータストアへのアクセスは、全てRepositoryを介して行われます。この際、データス
MVCの話もっとしてほしい - ✘╹◡╹✘
昨日バイト先で男子しか参加しない女子会して、開発の仕方どうするかみたいな話合いしたの面白かった。 押し付け合い回避のためにもレイヤ 趣味や価値観をリアルタイムで押し付け合うのはギスギスして良くないが、話し合うべきときを設けてやはり定期的に話し合うべきだと思った。コード内のインターフェースが少ないと、そういう押し付け合いが起こる可能性が多く出てきたり、それを避けるために心理的に間違った方向に実装しそうで良くない。データAPIが薄くてコントローラに書くことが増えると、コントローラ内で押し付け合いやすいみたいなそういう。レイヤ分けて「はい俺バリア〜ここからさき俺の実装〜〜」みたいなのが良さそう。 MVC界隈の知識源 MVC関係の話、まとまった情報源が無くて、Togetterかブログエントリあたりで適当にまとめられていることが多い。PoEAA(Patterns of Enterprise Appl
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
