MVCのモデルを分割する方法 - 浜村拓夫（・∀・）作品集
MVCフレームワークでWebアプリケーションを作成するとき、肥大化していくモデルをどのように分割すれば良いのか？悩みます。 いつもは適当にやっているのですが、だんだんファイル数、クラス数、メソッド数が増えてくると、把握しづらくなって、辛くなってきますｗ 他の人のやり方を参考にして、モデルを適切に分割する方法を検討してみました。 ●Webアプリとは？ Webアプリの特徴は、インターネットをはさんで、 (1) クライアント側 (2) サーバー側 に分かれていることです。 サーバー側は、 (a) DB（データを置いておく場所。通常はリレーショナルデータベース） (b) DBのラッパー（CRUDを担当するアプリケーション層） に分かれています。 で、このラッパー部分(b)に、MVCフレームワークを使っています。 (via もみじ饅頭（こしあん）：もみじ饅頭のやまだ屋) MVCフレームワークは、 (
私がMVCフレームワークをもはや使わない理由
数ヶ月前、私はなぜここにたどり着き、何が可能かを理解する旅に出ました。この旅は、私にアプリケーションアーキテクチャ、MVCという強烈な宗教に対する疑いをもたらしました。そして、リアクティブ、関数型プログラミングの真の実力に触れたのです。また、シンプルさに集中する旅でもあり、私たちの産業はうまくやっているという考えを捨てる旅でもありました。どんなことを見つけたか興味がある方もいるでしょう。 私たちの見ている画面の背後にあるパターンはMVC –Model-View-Controllerです。まだウェブがなくソフトウエアアーキテクチャも分厚いクライアントが単一のデータベースに原始的なネットワークでアクセスするのがせいぜい、という時代にMVCは生まれました。そして数十年後、MVCはまだ現役であり、衰え知らずでオムニチャネルアプリケーションの開発に使われています。 Angular2のリリースの前にM
オブジェクト指向プログラミング再入門
24. よくない設計 ! ／￣￣＼ ／ _ノ ＼ | （ ●）（●） | （__人__） | ｀ ⌒´ﾉ | } ヽ } ヽ､.,＿＿ __ノ _, ､ -― ''"::l:::::::＼ｰ-..,ノ,､.ﾞ,i ､ /;;;;;;::ﾞ:':､::::::::::::|＿:::;､>､_ l|||||ﾞ!:ﾞ､-､_ 丿;;;;;;;;;;;:::::i::::::::::::::／:::::::＼ﾞ'' ﾞ||i l＼>::::ﾞ'ｰ､ . i;;;;;;;;;;;;;;;;;;;;;;|::::::::::::::＼::::::::::＼ .||||i|::::ヽ::::::|:::! 年齢は？ 店員（売る人） ! ／￣￣＼ ／ _ノ ＼ | （ ●）（●） | （__人__） | ｀ ⌒´ﾉ |
社内勉強会でオブジェクト指向についてLTしました | Nekoya press
毎週定例の社内勉強会でオブジェクト指向の基礎についてLTしました。資料はやや加筆しています。 昨今、オブジェクト指向というとMVCとかデザインパターンみたいな発展的なトピックが目立つような気がしていて、もっと簡単に考えればいいのになーという思いからこういう話をしました。 凝集度を高める設計指針を出来るだけ平易な言葉で語ろうというのがコンセプトでした。 サンプルがいろいろ話をはしょりすぎで、改めて見るとちょっと違和感ありますね… 開発のバイトで来てくれてる学生の子たちに、こういう概念的な話を聞いてもらう機会って積極的に作らないとなかなかないので、そういう場を作っていくのもおっさんの役割なのかなーみたいなことを思ってます。
開発者が知っておくべき、6つのUIアーキテクチャ・パターン - ＠IT
.NET開発者中心 厳選ブログ記事 開発者が知っておくべき、6つのUIアーキテクチャ・パターン ―― 「matarillo.com」より ―― 猪股 健太郎 2011/12/15 「.NET開発者中心 厳選ブログ記事」シリーズでは、世界中にある膨大なブログ・コンテンツの中から、特にInsider.NET／.NET開発者中心の読者に有用だと考えられるブログ記事を編集部が発掘・厳選し、そのブログ記事を執筆したブロガーの許可の下、その全文を転載・翻訳しています。この活動により、.NET開発者のブログ文化の価値と質を高め、より一層の盛り上げに貢献することを目指しています。 Martin Fowler氏の『GUI Architectures』を訳して公開しようと思ったのだが、FAQページに「PofEAAの続編などは商業出版する予定なので翻訳はしないでほしい」と書いてある。なので翻訳の公開はやめて、「
MVPVM 設計パターン - WPF 向けのモデル - ビュー - プレゼンター - ビューモデル設計パターン
このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。 WPF 向けのモデル - ビュー - プレゼンター - ビューモデル設計パターン Bill Kratochvil コード サンプルのダウンロード これまで私が携わり、成功を収めたすべてプロジェクトのうち、もっとも成功を収めたプロジェクトには共通する成果があります。それは、アプリケーションの規模が大きくなるほど、コード ベースが小さくなる、というものです。一見矛盾しているように思えますが、アジャイル環境でコーディングを行うと、コード ベースが小さくなります。要件が変化するにつれて、リファクタリングが行われます。こうしたリファクタリングの際に開発後に明らかになった情報を組み合わせて、既存コンポーネントの再利用効率
モデル・ビュー・コントローラ - Trygve Reenskaug - Digital Romanticism
この記事はTrygve Reenskaug氏の記事「MODELS - VIEWS - CONTROLLERS」を、氏の許可を得て翻訳したものです。（原文公開日：1979年12月10日） モデル モデルは知識の表象です。モデルは１つのオブジェクトであるかもしれませし（あまり面白くはありませんが）、複数のオブジェクトからなる構造かもしれません。 モデルとその一部には一対一の対応関係がある一方で、モデルとその所有者によって知覚された世界の表象との間にも一対一の対応関係があります。したがって、モデルの各ノードはその問題における識別可能な一部分を表象しているのです。 モデルの各ノードは、同一水準の問題を扱うものでなければなりません。問題指向の各ノード（例えば、カレンダーの予定）を実装の詳細（例えば、パラグラフ）と一緒にすることは混乱を招きますし、良くない形式と考えられます。 ビュー ビューはモデルの
MOVEは望まれなかった子 - the sea of fertility
なにやらMOVEが話題です。 MVC is dead, it’s time to MOVE on. http://cirw.in/blog/time-to-move-on [翻訳]MVCは死んだ。MOVEするときがきた きしだのはてな http://d.hatena.ne.jp/nowokay/20120704 Twitterで「”MOVEは生まれた瞬間死んだ” って記事まだー？」って騒いでたら「お前が書けよ」の流れだったので息抜きに書きます。息抜きなので図が無いのは勘弁してください。 MOVEが生まれていない理由 この文中ではMOVEが生まれた理由はMVCの問題点に関わるとされており、そのMVCの問題点としてされているのは次の２点です。 MVCではControllerが肥大化する MVCは10年古い技術で設計されていて、最新のプログラミングパラダイムに対応していない。 しかしこの理由のう
MVCは死んだ。MOVEするときがきた - きしだのHatena
Conrad Irwinさんの「MVC is dead, it's time to MOVE on.」を訳してみました。 MVC is dead, it's time to MOVE on. この訳文も原文のライセンスを引き継いでCC-BY-3.0ライセンスで利用可能とします。 追記13:58 すでに訳してた方がいました。MVCの時代は終わった。MOVEを使い始めましょう。 - ふじこのプログラミング奮闘記 MVCは死んだ。MOVEするときがきた MVCはすばらしいアイデアだ。モデルを持ち、モデルは内部に少しの状態をもつ。ビューは内部に少しのUIをもつ。そして、コントローラは内部に少しの・・・ 何を持つ？ 私は確かにこのことに気づいた最初の人物ではない。しかし示されたようなMVCの問題のために、あなたは最後には過剰なコードをコントローラに詰め込むことになる。なぜなら、他にどこに入れていいか
グーグル製のJavaScript MVCフレームワーク「AngularJS」、正式版が公開 − Publickey
グーグルは、JavaScriptでMVCアーキテクチャのアプリケーション開発をする際に便利な機能を備えたライブラリ「AngularJS 1.0」のリリースをブログで発表しました。 MVCアーキテクチャとは、ソフトウェアがデータモデル（Model）の部分とユーザーインターフェイスの部分（View）、そしてビューとモデルのあいだで制御する部分（Controller）に分離された構造のことを指します。 これらが分離されているとプログラムの見通しがよくなり変更にも対応しやすく、テストも容易になるため、何種類ものユーザーインターフェイスと複雑なロジックなどから構成される大規模なアプリケーションではMVCアーキテクチャの採用が望ましいものと考えられています。 しかしWebアプリケーションをMVCアーキテクチャで実現しようとすると、ビューの役割を果たすHTMLのコードの中に、どうしても複雑なJavaSc
俺が勝手に考える正しいMVCの実装。モデルはデータAPI！ - はかますたいる！きょろの技的雑記
最近、一緒にコードを書く人（特にRailsから始めた学生さん）に、 MVC（Model - View - Controller）において、「model = DB」だと考えている人が多いなぁと感じたので、このあたりに関する自分の考えをまとめて書いておきます。 あくまで俺の考えなので、違ってたらごめんね。 MVCをちゃんと理解している人には当たり前すぎる話かもなのでスルーでよろしく！ 初学者はViewをモリモリ生やす これはプログラミングを始めた人なら誰でも経験ありますよね。 むしろ、MVCとか始める前の、誰でも経験あるであろう <?php print '<a href="${hoge}">link</a>'; なんてのは完全にViewだけで実装されたプログラムですね。 最近のMVCのテンプレートはとても高機能です。 変数の宣言も、条件処理も、ループも、プログラム言語としてひと通りの「逐次、反
MVVMパターンの適応 – 2011年のMVVMパターンの常識 - the sea of fertility
MVVMパターンに関する認識・知見があちこちに散らばっているように見えるので、そろそろまとめてみる事にしました。この記事は、他の各サイトの記事などでMVVMの基本的な考え方・実装方法などを把握されている方が対象です。 そういった方がMVVMパターンを実務に適応してみようと思った時や、MVVMパターンを要件に合わせてカスタマイズしていく際に、認識すべきパターンの実装方式のそもそもの理由と考え方、要件に合わせて考えていかなければならないポイントを把握する助けとなる情報を提供するのを目的としてこの記事を書きました。(文字ばかりですいません＞＜) MVVMの実装の各要素の実装をこねくりまわすばかりで、その過程でパターンを把握している気になって、パターンの本来の目的を破壊してしまうような実装を推奨してしまっている人も見ます。そんな滑稽な事をしない認識を持って欲しいのです。 MVVMパターンは、WPF
Web Applicationを綺麗に設計するためのMVACという考え方 - $shibayu36->blog;
【2016/03/04追記】以前まとめたこのMVACという名前の設計は既に古くなっており、今はこのようなアーキテクチャで設計していません。 こんにちは。最近ははてなでMVACというアーキテクチャに則って開発をしているのですが、ようやく意味を理解できてきました。そこで今回は「Web Applicationを綺麗に設計するためのMVACという考え方」について、サンプルを交えながら説明していこうと思います。かなり長くなってしまったので、時間があるときにでもどうぞ。 MVACって？ データソースやロジックを扱う「Model」、表示・出力を管理する「View」、複数のModelとControllerをつなぐApplication、ユーザのリクエストなどを受け取りViewやApplicationを制御する「Controller」の4つの要素を組み合わせてシステムを実装する方式。MVCをさらに抽象化した
Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
Webプログラミングは何故オブジェクト指向でない？～WicketはWebプログラミングにオブジェクト指向を取り戻す - プログラマの思索
Webプログラミングは何故オブジェクト指向でない？～WicketはWebプログラミングにオブジェクト指向を取り戻す JavaでWebアプリを10年書いて思ったこと。 Webプログラミングは全然オブジェクト指向でない。 Sevlet＋JSP主体のプログラミングスタイルは、リクエストとレスポンスへPrimitiveな値をどうやって渡すか、という手続き型の発想でしか書いていない。 従来のWebプログラミングスタイルの問題点について書いてみる。 以下ラフなメモ書き。 【参考リンク】 Wicketって？ ウェブ開発をもう一歩前に Wicketで始めるオブジェクト指向ウェブ開発：第1回 Hello, Wicket｜gihyo.jp … 技術評論社 【コラム】イマドキのIDE事情 (39) Wicket、Grails、Click - IDEでみる軽量Javaフレームワーク | エンタープライズ | マイ
第1回 ASP.NET MVCフレームワーク 基本のキ
従来とはまったく異なる手法でASP.NET Webアプリを構築するASP.NET MVCとはいかなるものか？ 新しいフレームワークを基礎から学ぶ。 連載目次 いまさら声を大にしていうまでもなく、ASP.NET技術はWebアプリケーション構築のための優れた、また、魅力あるアーキテクチャだ。開発生産性、管理性、拡張性などなど、ASP.NETの魅力を表すキーワードについては、すでに多くの記事によって語り尽くされているところでもあり、本稿であえて繰り返すまでもない。詳細については、連載「プログラミングASP.NET」や「Visual Studio 2005でいってみようDBプログラミング」などを併読していただくとよいだろう。 もっとも、そんなASP.NETにも問題がないわけではない。 1つに、単体テストの実施が容易でないという点。諸兄もご存じのように、Webフォームは基本的にページ（Pageオブジ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
