タグ

関連タグで絞り込む (0)

  • 関連タグはありません

タグの絞り込みを解除

mvcに関するtacchiniのブックマーク (6)

  • MVCのモデルのあり方について考えた - 130単位

    deeekiモデルとかエンティティとかDAOとかDTOとかの自分の中での定義付けをはっきりさせときたい ( 2010-04-03 16:48:21 ) 既存Webアプリのコードを踏襲しながら新規開発、なんてことをしています。そこで立ち止まったのが、MVCアーキテクチャのモデルについて。モデルという言葉の定義が難しいですが、RDBMSを利用する場合テーブル毎に対応するもので、ロジックを主に記述するものという捉え方でいます。そのモデルですが、ざっくりと「データアクセスロジック」と「データそのもの」に分けられると思います。 既存コードでは、データアクセスとデータそのものが一つのクラス/オブジェクトでまかなわれていました。つまり、自身でテーブルのカラムに対応したプロパティを持ち、自身にupdateやらdeleteやらのメソッドを持つというものです。 この構造になんとなく違和感を持ったまま開発をして

    tacchini
    tacchini 2012/09/26
  • Ruby on Railsの「えせMVC」の弊害

    先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC(Model View Controller)がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの(コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること)を避

    tacchini
    tacchini 2012/09/26
  • Web アプリの MVC 設計まとめ - もやし日記

    MVC 設計について考えていたときに、ちょうどその辺りの話をされている方々が居たので、今の考えをまとめてみました。 目次 前提 肥大化するコントローラを避ける ビジネスロジックをどこに書けば良いのか コントローラとモデルの間にもう一つの層があるとうまくいく? まとめ 前提対象は Web アプリケーションで、画面数(ビューの数)は数個〜100個程度の規模です。WordPressTwitter、37signals のサービスのようなものを作ろうとするとき、どういう MVC 設計をしていくかについて考えます。巨大なシステム、金融系システム、基幹系システムなどを作る場合とは異なる考え方もあると思います(そもそも MVC を使わない、など)。 肥大化するコントローラを避ける例えば、八百屋さんで「60円で仕入れたリンゴ1つを100円で売った」こと(Sales Transaction)を記録する場合を

    tacchini
    tacchini 2012/09/26
  • CakePHPを使ったMVC設計のベストプラクティス - Sooey

    CakePHPを使ったMVC設計のベストプラクティス 個人的にはCakePHPはあまり好きではないのですが、CakePHP開発メンバーによるMVCデザインの記事 (CakePHP のおいしいべ方)で紹介されていたBest Practices in MVC Design with CakePHP (php|architect’s C7Y)はMVCフレームワーク利用者にとってとても有用な情報だったので、訳してみました(php|architectの方には翻訳許可を頂いています)。 この記事を読んでドメインモデルに興味を持った方は、エンタープライズ アプリケーションアーキテクチャパターン(PoEAA)やDomain-Driven Design: Tackling Complexity in the Heart of Softwareに手を出してみるのもいいかも。他に、InfoQにユーザー登録すれ

    tacchini
    tacchini 2012/09/26
  • 自己流MVC開発体験記 - 130単位

    新規の開発をやり遂げるために - 130単位 この記事から一週間経ちました。開発していて悩んだ点とか現在の状況をメモ書きしてみます。(言語はPHPで、CRUDに多少毛の生えた感じのWordPressプラグインを作っています) 開発経過 DBとやり取りするModelクラスを作成 プライマリキーのカラム名で悩む 単純に「id」がいいのか 「モデル名 + id」がいいのか → 今のところ「id」 データの入れ物で悩む 最初に連想配列をメインで使うことに決めた けどWordPressは$postや$userなどオブジェクトを使ってる ついでに連想配列よりオブジェクトの方がタイプ数が2少なく済むことに気づく $data['xxx']と$data->xxx けどDBへの保存は連想配列を使うので悩ましい → 今のところ連想配列 (あとで変えるかも) DBアクセスのみ分離した状態で進める 新規作成に加えて

    tacchini
    tacchini 2012/09/26
  • CakePHP開発者が知るべき10のこと

    先日、こんな記事が上がっていました。 Android開発者が知るべき10のこと この記事でまとまっているのは、Android開発において必要な10の項目です。 インターフェースの設計から、データの取り扱いまで。 AndroidはモバイルデバイスのOSで、CakePHPは単なるWebフレームワーク。 しかし、予め用意されたルールやAPIを活用する点は同じです。 つまり、フレームワーク全般において、開発者が知るべきことをまとめることが出来るはずです。 ここでは、私が良く利用するCakePHPフレームワークについて、開発者が知るべき10のことをまとめます。 1. CakePHPで良いのか CakePHPを使う際に、知るべきことその1。 それは、あなたは当にCakePHPを使うべきなのかということです。 現在、あらゆるフレームワークが溢れ返っています。 Ruby Ruby On Rail

    tacchini
    tacchini 2012/09/26
  • 1