Patterns of Enterprise Application Architecture - Martin Fowler's Bliki (ja)
Martin Fowler氏とAddison-Wesley Pub Coの許可を得て、パターンカタログの翻訳を行っています。 ※書籍の邦訳とは一切関係ありません。 PofEAAのパターンカタログから読始めるとよいでしょう。 パターンカタログの日本語版 パターンカタログの英日対応表 上記のカタログでは書籍の訳語を踏襲していますが、各ページでは「できるだけ正しい」訳語を使うようにしています。邦訳版のパターン名に関する議論などは、JapanesePatternNamesを参照。 ページ一覧 アクティブレコード アプリケーションコントローラ 関連テーブルマッピング BBS パターンカタログ パターンカタログの比較表 パターンカタログ（日本語） クラステーブル継承 クライアントセッションステート 粗粒度ロック 具象テーブル継承 データマッパー データ転送オブジェクト データベースセッションステート
Minimal Cake Pattern のお作法 - Qiita
追記 (2020-12-27) より基礎的な説明を Minimal Cake Pattern 再考 にまとめました。Minimal Cake Pattern という言葉を初めて聞く人は、こちらの記事を先に読むことをおすすめします。 Scalaにおける最適なDependency Injectionの方法を考察する 〜なぜドワンゴアカウントシステムの生産性は高いのか〜 で紹介されている Minimal Cake Pattern をもう少し詳しく解説します。 Minimal Cake Pattern それ自体は自明なものですが、いくつかの規約に従わないと混乱を招きます。以下の事柄を覚えておくと良いでしょう。 MixIn に extends はいらない trait UsesSomething { def something: Something } trait MixInSomething ext
Webアプリケーションのサービスクラスとは何か - 虎塚
「JSP、サーブレット、サービス、DAO、DTOといった構成のアプリケーションにおけるサービスクラスとは何か」、という問いに自分なりの答えを出すのが、今日の宿題です。 自分の解答 ※注意: 以下の文章は言い切り形式で書いていますが、間違っているかもしれません。 ちょろっと調べたのですが、サービスについてそのものズバリの単一な定義を見つけることはできませんでした。なので、いくつかの観点から理解することを試みます。 モデル、ビュー、コントローラにおける「サービス」 アプリケーションをモデル、ビュー、コントローラに分けて見たとき、サービスはモデルに属します。モデルには、データベースアクセスを行うクラスと、システム固有の処理を行うクラスがあります。 サービスは、後者のシステム固有の処理を行うクラスに当たります。 なお、データベースアクセスを行うクラスは、データを保持するクラスと、データベースアクセ
リソースモデリングパターン
Webアプリケーションについて、RESTfulなURL・リソース設計のパターンを見出すことで、 どのパターンかを判断するだけで、既存の Good Practice が適用できる 名前をつけて呼べるようにしたい Railsなどのフレームワークで簡単に適用できるようにしたい ということを目指しています。 ほんとうに役立つか これはパターンと言えるのか もっと他にもある だいぶ粒度がバラバラ 名前の付け方（パターンは名前重要） など、ぜひご意見をください。 パターン Collection & Member Resource パターン Singular (Singleton) Resource パターン Filtered Collection パターン Filtered Subresource パターン Multi-member Resource パターン Partial Resource パター
GitHub - tcorral/Design-Patterns-in-Javascript: Design Patterns applied to Javascript code.
Design Patterns in Javascript ES6 This will be a repository of how to use the Design Patterns from Gang of Four in your applications with Javascript. Update: Added Flyweight implementation. Added Bridge implementation. Added Prototype and Builder implementations. All the Design Patterns have been refactored to ES6. Added the Multi-Inheritance Design Patterns exclusive for ES6. Added new Design Pat
Inversion of Control コンテナと Dependency Injection パターン
以下の文章は、Martin Fowler の「Inversion of Control Containers and the Dependency Injection pattern」を、かくたにが翻訳したものです。原著者の許可を得て翻訳・公開しています。 翻訳にあたっては、kdmsnr さんにご協力をいただきました。ありがとうございます。公開後の改訂履歴を記事の最後に記述しています。 Java コミュニティでは軽量コンテナが花盛りである。 軽量コンテナは、異なるプロジェクトのコンポーネントをひとまとまりのアプリケーションとして組み立てることを支援する。 このようなコンテナの根底には、コンポーネントの結び付け方についての共通したパターンがある。 そのパターンのコンセプトは「Inversion of Control(制御の反転)」と、まことに包括的な名前で呼ばれている。 本記事では、このパタ
Jim Weirich さんから学ぶ DI(Dependency Injection) - わからん
PHP コミュニティでは今、DI コンテナが花盛りです。良い機会と捉え、勉強しています。このブログ記事では、Jim Weirich さんの O’Reilly Open Source Convention August 1-5, 2005 での Vitally Important or Totally Irrelevant? というタイトルのプレゼン資料を紹介します。完全な翻訳ではなく、省略したりおぎなったりしています。間違いはコメント欄などでご指摘下さい。 この資料では、動的型付け言語である Ruby にとって DI は重要な設計方針なのかを、静的型付け言語である Java のサンプルコードを引き合いに出し論じています。これを読むことで、DI とは何かを(実際に動く)コードレベルから理解することができました。また、Ruby ならではの実装を知ることができました。しかし、Ruby にとって
ハタさんのブログ(復刻版) : JavaScriptでStrategyパターン。RPG風
結構前から遊んでたんだけど、ゆけ勇者が面白いなぁ。と思って、こんな感じなのを作るとするとどうなるんだろうかと思って、とりあえずStrategyパターンを使いつつ (中略) 今回の元ネタは ref- 指向性メモ::2005-02-24::JavaScriptでデザインパターンその3 になります。かなりパクった感じです。 # もう、6年も前のネタだったのか。ずっとブックマークにあった。重宝してます。 さっそく、実装コードはこんな感じ Function.prototype.bind = function(obj){ var __method__ = this; var __args__ = Array.prototype.slice.call(arguments); __args__.shift(); // obj return function (){ // concat args var
BeInteractive! [ArtisticCoding: データ通信の抽象化 (Abstract Query パターン)]
前回、前々回と、BEFoundation (って何？という方は→こちら) 内の再利用可能なクラスについて解説しました。しかし、オブジェクト指向では、実際のコードやクラスとなっていなくても、再利用可能なものがあります。そう、設計、いわゆるデザインパターンというヤツです。ライブラリと違って、デザインパターンは文書化しないとなかなか見えない・残らないものなので、仕事で使って有効だと思ったものなど紹介していきたいと思います。 今回は、データ通信を抽象化するためのパターンです。個人的に Abstract Query パターンと呼んでいますが、名前をわざわざ付けるほどオリジナリティがあるかは微妙です。事実、実体としては Abstract Factory ほぼそのままで、考え方としては、サーバーサイドではお馴染みであろう Data Access Object が近いです。 ここで言うデータ通信とは、次の
「RESTful MVC」なアーキテクチャの話
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）
Web アプリの MVC 設計まとめ - もやし日記
MVC 設計について考えていたときに、ちょうどその辺りの話をされている方々が居たので、今の考えをまとめてみました。 目次 前提 肥大化するコントローラを避ける ビジネスロジックをどこに書けば良いのか コントローラとモデルの間にもう一つの層があるとうまくいく？ まとめ 前提対象は Web アプリケーションで、画面数（ビューの数）は数個〜100個程度の規模です。WordPress、Twitter、37signals のサービスのようなものを作ろうとするとき、どういう MVC 設計をしていくかについて考えます。巨大なシステム、金融系システム、基幹系システムなどを作る場合とは異なる考え方もあると思います（そもそも MVC を使わない、など）。 肥大化するコントローラを避ける例えば、八百屋さんで「６０円で仕入れたリンゴ１つを１００円で売った」こと（Sales Transaction）を記録する場合を
大きいMVCと小さいMVC 語弊を恐れずに書く - When it’s ready.
MVCって、大抵の場合サーバサイドでの実装の分け方の事を言ってるのが多い気がする。んで、サーバサイドを作ってる人々の多くは、UIに関してはデザイナーがhogehogeとか、タンポポワークほげとか言ってる場合が多い気がするんだけど、実際どうなんだろう？ 保存が必要なければ、ブラウザ内のJSだけでノートラフィック（初回DLは除く）でかなりのことが出来ると思うし、凝ったところはそうなっていると思う。MVCをサーバサイドとクライアントサイドで分けて考えると、実装者のリソースやら各データの祖結合具合だったりというのが上手に調整出来ると思うんだけどどうなんだろ？モデルにロジックてんこ盛り、否、コントローラも頑張るべきとか、いやいやテストすればモーマンタイでしょとかそう言うレベルじゃない気がする。 サーバーから動的に渡す部分はすべてJSONにして、それをサーバー側では最終アウトプット（View）にする、
llameradaの日記 - JavaScript でマルチスレッド・デザインパターン
JavaScriptでデザインパターンを書いてみる。とはいえ、いまさらFactoryパターンなど書いても面白くないので、マルチスレッド・デザインパターンにする。 もちろん、JavaScriptの言語仕様にスレッドなどない。しかし、ブラウザ環境では実質的にスレッドが存在する。スレッドが発生する場面には２種類ある。１つは、イベントである。例えば、ユーザのクリック動作によってonclickイベントが発生した時、onclickイベントハンドラだけを処理するスレッドが発生するとみなせる。もう１つは、setTimeoutとsetIntervalメソッドである。これらのメソッドでは、一定時間後に、別の処理を実行させるが、この処理は現在の処理と並行的に実行される。つまり、スレッドとみなせる。個人的には、setTimeoutをアニメーションなどの小細工だけに使うのはもったいないと思う。setTimeoutの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「『DCI なんて面倒なだけで Service 使えばいい』への返答」を読んだ感想とポエム
dbpatterns.com
Rubyで学ぶデザインパターン
http://1431.7614.org/
scala-study-group/patterns at master · greedy/scala-study-group
ZURB U | Library
http://www.littlespringsdesign.com/blog/category/ui-design-patterns/