Laravel におけるリポジトリ実装のポイント - Shin x Blog
Laravel を使った開発でも、ドメインロジックと RDBMS などの永続化層へのアクセスを分離するためにリポジトリパターンを採用するケースが増えてきました。 ただ、Laravel には Eloquent という Active Record タイプの ORM があるので、これとリポジトリをどのように組み合わせるかで悩んでいる人が多いようで、これまで開発現場や勉強会などで質問を受けることがありました。 本エントリでは、リポジトリを実装してきた経験を元に、私が考える実装のポイントをご紹介します。 1. ドメインデータの入出力にリポジトリパターンを使う 2. メソッドの型宣言にドメインデータを指定する 3. 機械的に CRUD メソッドを実装しない 4. Eloquent を利用したリポジトリクラスの実装 5. 複数テーブルを扱うリポジトリ 6. Paginator との連携 さいごに 1.
やはりあなた方のDependency Injectionはまちがっている。 — A Day in Serenity (Reloaded) — PHP, FuelPHP, Linux or something
今日はPHP界隈で大人気のDependency Injectionと、それに関連する用語について整理しておこうと思います。 以下のような状況があるのではないか？と思ったからです。 多くのPHPユーザがDependency Injection（DI）をよくわかっていない、あるいは正確に説明できません。 そして、デザインパターンである「DIパターン」とDIをサポートするツールである「DIコンテナ」を混同しています。 また、「DIパターン」と「サービスロケータパターン」をうまく区別できていません。 Dependency Injectionとは何か？ Dependency Injectionとは「Dependency」を「Injection」するというデザインパターンです。 日本語では何故か「依存性の注入」と訳されており、これが混乱の元ではないかと思います。 日本語で「依存性」と言うと、「依存性は
リポジトリ - Strategic Choice
リポジトリ＠オブジェクトリレーショナルメタデータマッピングパターン「仕様」を満たすデータ取得レイヤ。どういうこと？リポジトリは、ドメイン層とデータマッピング層を仲介し、ドメインオブジェクトに対してコレクションのようにアクセスできるインターフェースを提供します。リポジトリにより、クライアントは、「仕様」を満たすコレクションを、クエリオブジェクトやクライテリアを使用することなく、宣言的に取得することができます。どうすれば？リポジトリは、ドメインオブジェクトに対して、データマッパーの検索を隠蔽します。リポジトリは、内部的に『クエリーオブジェクト』を生成して検索を実行し、クライアントには単純な検索インターフェイスだけを公開します。どうして？データマッパーは、ドメインオブジェクトをデータベースアクセスコードから分離する「レイヤ」です。このよう構成の中で、クエリ部分を別途「レイヤ」化することには価値が
Visitor パターン再考 - Qiita
オブジェクト指向 Advent Calendar というものを見つけたので、Visitor パターンについて書いてみます。 嘘です Visitor パターンについて書きたいけれど、Java Advent Calendar は埋まってしまってるので、それっぽい Advent Calendar に参加しただけです。別に Advent Calendar に参加しないといけない決まりなんてないんですけど。 デザインパターン Visitor パターンとは、デザインパターンの一つです。 そもそもデザインパターンとは何かというと、1995 年に Gamma らが "Gang of Four"、俗にいう GoF で提唱した、オブジェクト指向プログラミングによって特定領域の問題を解決しようとする際に頻出するイディオムのようなものです。 GoF で提唱されたデザインパターンは多くありますが、1995 年に発表
Strategic Choice
Problemこのクラスは大きすぎて、もうこれ以上大きくしたくありません。「単一責務の原則」を適用してクラスを分割しようと思います。分割の具体的な方法がわかりません。Strategy「クラスの抽出」を適用します。どんなとき？「単一責務の原則」を適用してクラスを分割しようと思います。責務を把握したので、分割の実装を行いますが、具体的な方法がわかりません。どうする？「クラスの抽出」リファクタリングを適用します。ほとんどのレガシーシステムにおいて、最初にできることは、「実装レベル」で単一責務の原則を適用することです。つまり、大きなクラスから「クラスの抽出」をして、抽出クラスに委譲することです。「インタフェースレベル」で単一責務の原則を導入するには、より多くの作業が必要です。クラスの呼び出し側を変更しなければならず、テストも必要になります。まず、実装レベルで単一責務の原則を導入しておくと、将来イン
「MVVMパターンが必要な理由」啓蒙用資料公開 - the sea of fertility
MVVMパターン的な実装は、他のプラットフォームでは選択肢の一つにすぎませんが、WPF/Silverlight(Windows Phone 7 含む)においては唯一の選択肢です。コードビハインドを書かないことはMVVMパターンそのものの定義とは関係ありません。まずはスキルにあったレベルでMVVMパターンを意識した実装を初めてみませんか？ 以前の勉強会発表資料（わんくま勉強会での発表資料の半分以上をカットし、Androidテスト祭り分追加）を加工し、社内勉強会、そのほかの勉強会・ブログなどで自由に使える資料として公開します。私の個人名は抜いてあります。 無許可の改変・引用なども問題ありません。ただ、資料の直接の商用利用などはご遠慮ください。 ブログに張り付けたい場合、下のbマークから埋め込み用URLを取得できます。 「コードビハインドを書くのはMVVMパターンではない」などの誤解が、MVVM
O/Rマッピング技術の進化が皮肉にも助長している「えせMVC症候群」
昨日の「Ruby on Railsの『えせMVC』の弊害」というエントリー。若干「釣り」の要素が含まれたタイトルが功を奏したのか、たくさんのフィードバックがいただけた。そんな中で見えて来たのは、この問題はRailsに限った話ではなく、業務用アプリケーションで使われているJavaや.Netの世界でもよく見られる問題だということ。 その「問題」とは、ActiveRecordに代表されるO/Rマッピングの技術の進化が、本来のMVC（そしてオブジェクト指向そのもの）のメリットを無視した「えせMVC」な設計を助長している、という問題である。 ・MVCやオブジェクト指向を表面的にしか理解していないエンジニアが増えている（ここが根本的な問題） ↓ ・SQLを自分で記述しなくて良いO/Rマッピングはとても魅力的（これはこれで別の問題を含んでいるが、このエントリーではあえて突っ込まない） ↓ ・O/Rマッピ
ロジックをDBMS側に寄せるデザインパターン - aike’s blog
O/Rマッパー（ORM）かSQLか、という話が一部で盛り上がっていたので追いかけていました。 ORMについては以下のような見方をすることもできます。 「最初からあらゆる要素をオブジェクト指向で設計、実装すると決めた新規開発システムならばORMは有力な採用候補」 「非オブジェクト指向で設計、実装されたシステムにORMはあまり向いていない」 なので、すでに存在しているデータベース上で別の新しいシステムを構築するような場合は、ORMはあまり向いていないと思います。 O/Rマッピングツールに対する誤解をときたい - ITは芸術だ 引用したエントリはとても冷静にORMの利点を説明している良記事です。 この記事の内容には全面的に賛同しつつ、自分としてはSQL側からちょっと書いてみたいと思います。 以前、試しにクエリに付随するロジックをできるだけDMBS側（SQL）に寄せるようにして開発したことがありま
Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
OTN Japan - 今だからデータ・アクセスを真剣に考える！ 第2回
前回の「データベースことはじめ（前編）」では、システムの論理的な階層の中でドメイン層をどの様に実装するかということで、PoEAAのアーキテクチャパターンを元に見てみました。今回は、パーシステンス層のアーキテクチャパターン＋αを見ていきます。 まずパーシステンス層を見る前に、今回の話題とは直接ではないですが、間接的に関わってくる層のサービス層に関して少し触れておきたいと思います。サービス層は、ドメイン層配下のビジネスロジックをユーザインタフェース層やアプリケーション層から利用するためのインタフェースとして機能します。一般的にトランザクションロジックやセキュリティロジック、ドメインロジックのワークフロー等のドメインロジックとは直接関係ないロジックを含むのみで、大きなドメインロジックを含むことは好ましくないとされる層です。 では、パーシステンス層です。ここまで、役割的には、データアクセスの実装を
C#と諸々 ドメインモデル貧血症
C#がメインで他もまぁ諸々なブログです おかしなこと書いてたら指摘してくれると嬉しいです(´･∀･`) つーかコメント欲しい(´･ω･｀) Martin Fowler's Bliki in Japanese - ドメインモデル貧血症 有名なアンチパターンです。僕も昔やってしまったことがあります。 例えば、図書の貸出システムを作るとします。このシステムは利用者が直接操作し、借り入れ手続きや返却手続きを行います。 ドメインモデルを適切に適用した設計では、「書籍」クラスや「利用者」クラスを用意し、「利用者」クラスに「借りる」メソッドや「返すメソッド」を用意するでしょう。 public sealed class 書籍 { public int 管理番号 { get { ... } } public string タイトル { get { ... } } public string 著者 { get
具体例で説明するデザインパターン - てっく煮ブログ
JavaScriptデザインパターンってなんだかたいそうなものに考えられがちだけど、実は、そこかしこのライブラリや仕様に取り込まれていることが多い。「デザインパターン分からん」とか「で、どうやって使うのよ」と悶々としている人には、「どういうところで使わているのか」を知っておけばイメージも沸きやすいし、意外にたいしたことないんだな、ということが分かるんじゃないだろうか。そこで、JavaScript やその周辺の技術で、デザインパターンがどのように使われているかを紹介してみることにする。ここでは、GoF本の順番に沿って、以下の11個のパターンを取り上げる。生成に関するパターン Factory MethodAbstract FactoryBuilderPrototypeSingleton構造に関するパターン AdapterComposite振る舞いに関するパターン Chain Of Respon
The life of an HTML HTTP request - MDC
(1) URL の読み込みは、（Webshell の中の LoadURL か LoadURI の一種から呼び出される）nsWebShell::DoLoadURL の中から始められます。Webshell は、その DocumentLoader が特定の URL を読み込む（"view" コマンドの実行する）ことを知らせます。[メモ: nsWebShell.mObserver を nsIStreamObserver として、webshell を nsIContentViewerContainer として DocLoader へ通過させる。] (2) DocumentLoader は、要求されたファイルの転送を始めるために、URL 付きで NS_OpenURI を呼び出します。Necko (ネットワークライブラリ）は URL のスキーマ（URL の最初の部分、この場合 http:）をチェックし、
Sample Application for GOF's Design Pattern
COMPSITE は、オブジェクト指向設計されたソフトウエアの至る所で見ることができます。オブジェクト指向設計の王様 といってもよいでしょう。その中でも、もっとも分かりやすい例は、OSのファイルシステムです。ファイルシステムは、ディレクトリとファイルを特に意識することなく操作することができます。COMPSITEは、この難しそうな課題を、いとも簡単にやってのけます。 この COMPSITEパターンを利用して、ファイルシステムを設計するという例が、参考文献[4]に記述されていますので参考にしてください。とってもいい本ですよ。お勧めです！ その他にも COMPSITE は、ドキュメントのデータ構造を表現するのにとても適してます。ドキュメントを処理する（良く出来た）ソフトウエアは、ほとんど例外なく COMPSITE をベースとした設計となっているはずです。その中でも有名なのは、いわずと知れた、Do
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: 実装パターン: ケント・ベック (著), Kent Beck (著), 永田渉 (読み手), 長瀬嘉秀 (読み手), 永田渉 (監修), 長瀬嘉秀 (監修), 株式会社テクノロジックアート (翻訳): 本
Amazon.co.jp： デザインパターンとともに学ぶオブジェクト指向のこころ (Software patterns series): アラン・シャロウェイ, ジェームズ・R・トロット, 村上 雅章: 本
Sample Application for GOF's Design Pattern
Phactory: Django: モデルクラスを継承したフォームクラスの値を途中で変更する方法
デザインパターン[モデリング] -TECHSCORE-