[Video] http://www.youtube.com/watch?v=s1dhXamEAKQ TildのYehuda KatzのGolden Gate Ruby Conference 2013での講演。 Ruby on RailsのクリエーターであるDavid Heinemeier Hanssonが、「JavaScript勢はダブルMVCで苦しんでいる。サーバとクライアント両方にMVCが必要で複雑すぎる。」とTwitterで発言したのに対して、Yehudaは、それでは誤解を与えると危惧し、GUIプログラミングが歴史的にどのようにMVCに発展してきたかを紹介することで、ダブルMVCが本当に意味するところを解説しています。 DHHの発言は、盛り上がってきたMeteor / Node.js勢に対する単なる批判っぽいですが、それに対してYehudaはロジカルに話をまとめてます。 スライドを

以下の文章は、Martin Fowler の「Inversion of Control Containers and the Dependency Injection pattern」を、かくたにが翻訳したものです。原著者の許可を得て翻訳・公開しています。 翻訳にあたっては、kdmsnr さんにご協力をいただきました。ありがとうございます。公開後の改訂履歴を記事の最後に記述しています。 Java コミュニティでは軽量コンテナが花盛りである。 軽量コンテナは、異なるプロジェクトのコンポーネントをひとまとまりのアプリケーションとして組み立てることを支援する。 このようなコンテナの根底には、コンポーネントの結び付け方についての共通したパターンがある。 そのパターンのコンセプトは「Inversion of Control(制御の反転)」と、まことに包括的な名前で呼ばれている。 本記事では、このパタ

2013年4月13日追記: PHP 5.5 で finally 句が追加されたので Loan パターンを追記しました。 Closure Design Patterns で紹介されている Groovy のコードを PHP に翻訳しました。無名関数とクロージャを区別しても情報が分散してしまうのでクロージャに統一しました。Method Combination (関数合成)は省略しました。原文ではカリー化(currying) と書いている箇所を部分適用 (partial application) に訂正しました。カリー化と部分適用の違いについてはこちらのブログに解説があります。Groovy コアに本当のカリー化メソッドを採用することへの要望があり、長期的には取り込まれる見込みのようです。 これらのパターンは Venkat Subramaniam 氏および Neal Ford 氏のプレゼン資料から抜

書籍「エンタープライズアプリケーションアーキテクチャパターン」の、オブジェクトリレーショナルデータベースに関わる部分をまとめます。第11章　オブジェクトリレーショナル振る舞いパターン第12章　オブジェクトリレーショナル構造パターン第13章　オブジェクトリレーショナルメタデータマッピングパターン一覧「オブジェクトリレーショナル振る舞いパターン」（Object-Relational Behavioral Patterns） ユニットオブワーク（Unit of Work）一意マッピング（Identity Map）レイジーロード（Lazy Load）「オブジェクトリレーショナル構造パターン」（Object-Relational Structural Patterns） 一意フィールド（Identity Field）外部キーマッピング（Foreign Key Mapping）関連テーブルマッピング（

書籍「エンタープライズアプリケーションアーキテクチャパターン」の、オフライン並行性に関わる部分をまとめます。第16章　オフライン並行性パターン前段知識オフライン並行性・前段知識：並行処理とはオフライン並行性・前段知識：安全性/活性とはオフライン並行性・前段知識：リクエスト/セッション/トランザクションとはオフライン並行性・前段知識：オフライン並行性とはオフライン並行性・前段知識：楽観的ロック/悲観的ロックとは一覧「オフライン並行性パターン」（Offline Concurrency Patterns） 軽オフラインロック（Optimistic Offline Lock）重オフラインロック（Pessimistic Offline Lock）緩ロック（Coarse Grained Lock）暗黙ロック（Implicit Lock）ソースコードasakichy/PofEAA＠githubPofEA

アクティブレコード＠データソースのアーキテクチャに関するパターン行データゲートウェイ＋ドメインロジック。どういうこと？アクティブレコードは、データベースの「レコード」に対して、ゲートウェイの役割を果たすクラスを作成します。１つのインスタンスが、テーブル内の１つの行にあたります。かつ、そのクラスに「ドメインロジック」を配置します。どうすれば？アクティブレコードのクラスは、レコード構造と一致させます。よって、クラス内の各フィールドは、テーブル内の各列と一致します。同時に、オブジェクトが保持しているレコードデータを追加・更新・削除するメソッドを提供します。ここまでは『行データゲートウェイ』と同じですが、アクティブレコードは、さらに、データに適用されるドメインロジックを実行します。また、検索メソッドも、このクラスに静的メソッドとして用意するのが通常です。どうして？アクティブレコードのクラスは、レコ

行データゲートウェイ＠データソースのアーキテクチャに関するパターン１レコード１クラス。どういうこと？行データゲートウエイは、データベースの「レコード」に対して、ゲートウェイの役割を果たすクラスを作成します。１つのインスタンスが、テーブル内の１つの行にあたります。どうすれば？行データゲートウェイはのクラスは、レコード構造と一致させます。よって、クラス内の各フィールドは、テーブル内の各列と一致します。同時に、オブジェクトが保持しているレコードデータを追加・更新・削除するメソッドを提供します。行データゲートウェイを使用する場合、検索メソッドをどこに置くのかが問題です。静的な検索メソッドを用意することも可能ですが、ポリモーフィズムの邪魔になります。独立した検索用オブジェクトを作成するのがベターです。どうして？行データゲートウェイは、レコードそのもののように見えるオブジェクトを提供します。クライアン

１テーブル１クラス。どういうこと？テーブルデータゲートウェイは、データベースの「テーブル」に対して、ゲートウェイの役割を果たすクラスを作成します。１つのインスタンスが、テーブル内のすべての行を処理します。どうすれば？テーブルデータゲートウェイは、データの受け渡しが役割なので、基本ステートレスです。テーブルデータゲートウェイは、データベースからデータを取得するための検索メソッドと、追加・更新・削除の各メソッドから構成されるシンプルなインタフェースを用意します。各メソッドは、引数をSQL呼び出しにマッピングし、データベース接続に対してそのSQLを実行します。テーブルデータゲートウェイは、特に『テーブルモジュール』に最適であり、テーブルモジュールが動作するレコードセットデータ構造を作成します。テーブルモジュールには、テーブルデータゲートウェイが唯一の選択肢です。どうして？テーブルデータゲートウェ

アプリケーションロジック。どういうこと？ビジネスロジックは2つ種類に分類されます。「ドメインロジック」と「アプリケーションロジック」です。「ドメインロジック」 ドメインでの問題を取り扱う。たとえば、特定のビジネスに特化した計算処理など。「アプリケーションロジック」 アプリケーションの責務を取り扱う。たとえば、担当者へのメール通知や、別の統合されたアプリケーションへの通知など。別名「ワークフローロジック」。サービスレイヤは、ドメインオブジェクトからアプリケーションロジックを分離します。サービスレイヤは、粗粒度のサービスを提供する層を生成して、アプリケーション境界を作成します。境界を通じて、クライアント側に操作のセットを提供します。アプリケーションのビジネスロジックをカプセル化し、その実装の中でトランザクションを制御し、応答を調停します。どうすれば？実装バリエーションには、「ドメインファサード

書籍「エンタープライズアプリケーションアーキテクチャパターン」の、レイヤ化アーキテクチャに関わる部分をまとめます。第09章　ドメインロジックパターン第10章　データソースのアーキテクチャに関するパターン第14章　Webプレゼンテーションパターン第15章　分散パターン一覧「ドメインロジックパターン」（Domain Logic Patterns） トランザクションスクリプト（Transaction Script）ドメインモデル（Domain Model）テーブルモジュール（Table Module）サービスレイヤ（Servic eLayer）「データソースのアーキテクチャに関するパターン」（Data Source Architectural Patterns） テーブルデータゲートウェイ（Table Data Gateway）行データゲートウェイ（Row Data Gateway）アクティブレ

ビジネスロジックをデータベースの表ごとに。どういうこと？テーブルモジュールは、データベース内のテーブル１つにつき１つのクラスを持つドメインロジックを構築します。クラスの１つのインスタンスには、データに対して動作する各種の手続きが含まれます。どうすれば？テーブルモジュールは、担当のテーブルのデータ操作メソッドをもたせます。振る舞いとテーブルのグループ化により、カプセル化の多くのメリットが得られます。テーブルモジュールは、インスタンスの場合もあれば、静的メソッドの集合の場合もあります。「テーブルモジュールのインスタンス」と「テーブルの種類」は１対１です。例えば「注文」の場合、ドメインモデルでは１つの「注文」に１つの「注文」オブジェクトが使われますが、テーブルモジュールでは、１つのオブジェクトですべての「注文」を扱います。どうして？テーブルモジュールは、テーブル指向のデータを前提とする構造を持っ

１ビジネスロジックを１メソッドで。どういうこと？ビジネスアプリケーションは、一連のトランザクションとして考えることができます。トランザクションには、データの単純な表示・登録や、ビジネスロジックが含まれています。トランザクションスクリプトは、ビジネスロジックを１つのメソッド（プロシージャ）にまとめて、データベースを直接ないし薄いラッパーを介して呼び出します。「トランザクション」という言葉を使用しているのは、ほとんどの場合、データベーストランザクションごとに１つのトランザクションスクリプトを使用しているからです。「スクリプト」という言葉は、「スクリプト言語」のことではなく、「コード片」を意味しています。どうすれば？それぞれのビジネスロジックが、それ専用のトランザクションスクリプトを持たせます。１ビジネスロジックに１トランザクションスクリプトなので、他のトランザクションスクリプトは気にする必要が

ビジネスロジックをオブジェクト指向で。どういうこと？ビジネスロジックにおいて、最も避けたい状況は、そのロジックが「複雑」になってしまうことです。とはいえ、現実のビジネスルールは多くのパターンを持ち、それを反映したロジックはとても複雑になりがちです。ドメインモデルは、この複雑性に「オブジェクト指向」をもって対応します。ドメインモデルは、対象となるビジネスエリアをモデル化したオブジェクトのレイヤを挿入します。ビジネスにおけるデータをモデル化するオブジェクトもあれば、ビジネスで使用するルールを扱うオブジェクトもあります。ドメインモデルは、データベースモデルと似ている場合もありますが、大きな違いもあります。ドメインモデルでは、データとプロセスが一体化され、複数値属性や複雑に絡み合う関係があり、さらに継承も使われています。どうすれば？シンプルなドメインモデルは、データベーステーブルごとに１つのドメイ

UIパターン 追記 この記事の一部を加筆・修正したものを「開発者が知っておくべき、6つのUIアーキテクチャ・パターン」として@ITに転載しています。 MVVMを追加した上で、アプリケーションモデルとMVVMをプレゼンテーションモデルのバリエーションとして位置づけました。 MVPの2つのスタイルとして、監視コントローラとパッシブ・ビューを説明しました。 まえがき Martin Fowlerの"GUI Architectures"を訳したので公開しようと思ったのだが、FAQページに「EAA developmentとかDSLなんかは商業出版するんで例外ってことで」と書いてある。面倒だったので翻訳の公開はやめて、「自分の理解を書く」というスタイルにしようと思う。 Fowler氏が説明しているのは 「フォームとコントロール」、「モデルビューコントローラー (MVC)」、「プレゼンテーションモデル」、

［技術講座］ DDD難民に捧げる Domain-Driven Designのエッセンス 第 1 回　ドメイン駆動設計とは 第 2 回　DDDの基礎と実践 第 3 回　大規模なプロジェクトへの適用 DDDパターンカタログ パターン名 参考訳 I. Putting the Domain Model to Work Ubiquitous Language ユビキタス言語 Model-Driven Design モデル駆動設計 Hands-On Modeler 実践的モデラー II. Building Blocks of a Model-Driven Design Layered Architecture 層状アーキテクチャ Smart UI （アンチパターン） 利口なUI Entities エンティティ Value Objects 値オブジェクト Services サービス Modules モジ