以下の文章は、Martin Fowler による Domain Logic and SQL の日本語訳である。 データベース指向ソフトウェア開発者とメモリ上(in-memory)アプリケーションソフトウェア開発者との間のギャップは、ここ数十年、徐々に広がってきている。このギャップが原因で、データベースの機能(SQLやストアドプロシージャ)をどのように扱えばよいのかという議論が数多く巻き起こっている。ここでは、ビジネスロジックを SQL に置くべきか、それともメモリ上のコードに置くべきかといった問題について、主にパフォーマンスと更新性の観点から考察を行う。考察には簡単な例を使うが、SQL クエリはしっかりとしたもの（rich SQL queries）を用いるので悪しからず。 エンタープライズアプリケーション（訳注：以下、EA）構築に関する本（私の近著『P of EAA』など）を読むと、ロジッ

従来のエラー処理は、フラグや戻り値から判定の判定で行っていた。 この方法では、このプログラムを利用するユーザに対してエラー処理を強制する力がないし、戻り値をエラー処理のためだけに潰してしまうことになるし、フラグを設定する側、フラグを判断する側と、二重にエラーチェックをしててすげー非効率だしで、つまり、ダメダメだったのである。 Javaでは、このことを踏まえ、try-catchという方法を採用している。エラー処理をほどこす場所にtryって書いておいて、エラーが起きたらcatchで何らかの処理をする。catch節はエラーの種類によって処理を変えることができる。 構造化手法の人にしてみれば、catch節にて出口が複数になるのを嫌だ！嫌だ！わーん！となるそうだが、例外処理が複数あっても、ぜんぜん構わない。むしろ、Javaの場合は、複数あるべき。 致命的なエラー（実行時エラー）と回復可能なエラー（チ

2007年7月20日を持ちまして社名変更致しました。 また、この社名変更に伴い、弊社ホームページのURLも以下の通り変更致しました。 http://www.robotics-e.co.jp 10秒後に自動で新サイトへ移動します。 もし移動しない場合は、恐れ入りますが上のURLより移動をお願い致します。

はじめに BluePrints では、すでに実績のあるアーキテクチャデザインを、デザインパターンとして再利用することを推奨しています。ソフトウェア業界では、多くの実績あるデザインパターンが使われている例があります。J2EE アプリケーションに適用されうる特定のパターンもいくつかあります。これらのパターンを使えば、優れた設計、コードの再利用、堅牢な設計を推し進めることができます。 モデル ビュー コントローラ (MVC) パターン 設計レベルでのデザインパターンを少し見ると、MVC パターンが、J2EE に適用可能なことがわかります。BluePrints を初めて見ると、BluePrints のガイドライン全体を通して、MVC パターンへの関連があることに気付くかもしれません。ここでは、MVC デザインパターンに関して復習し、どのように Web アプリケーションに適用できるかを見て

第1章 はじめてのデザインパターン はじめに デザインパターンとは 特集の構成 すぐわかるオブジェクト指向 すぐわかるUML おわりに 第2章 逆引きカタログ ロジック編 Singleton (シングルトン) Factory/Factory Method (ファクトリ/ファクトリメソッド) Strategy (ストラテジ) Composite (コンポジット) Visiter (ビジタ) 第3章 逆引きカタログ J2EE編 Template Method (テンプレートメソッド) Facade (ファサード) ViewHelper (ビューヘルパ) DAO (Data Access Object) 第4章 逆引きカタログ その他 ユーティリティクラス 実行時例外を標準的に使う Nullオブジェクト 第5章 デザインパターン適用の勘所 はじめに アプリケーションの仕様 リファクタリング前のサ

目次 概説 使い方(1) 使い方(2) 基本のAppender ファイル保存系Appender ネットワーク系Appender JMSAppender OSログ系Appender JDBCAppender その他のAppender 1.3で追加されたAppender フィルタ機能 Joran Hacks(1.3) 自前 Appender の書き方！(1.3) Chainsaw(1.3) アスペクトはお好き？ Log4cxxと小物ツール Log4php の使い方 Log4php の Appender たち もともとこの文書はバージョン 1.2.8 をベースに書いたものだが、2006年中に 1.3 がリリースされる、とアナウンスされていることもあり、フライングか？と思わなくもないが、1.3 対応をしました！ あと、どうも要望のありげな log4php についての記述を大追加！ 2007.9.1

→ [覚書] 「MVCモデル2」という表現は誤り ちょっと身の回りでよく聞くようになった表現なので、確認の意味で調べてみました。 MVCモデルに、モデル1, モデル2といった表現はありません。モデル1、モデル2という表現をするのは、「JSP〜」です。つまり、 JSP Model 1 : リクエストURIは *.jspで、リクエストを受け取ったJSPがビジネスロジックを実行してそれを表示するモデル。 JSP Model 1.5 : リクエストURIは *.jspで、JSPはuseBeanタグ経由でビジネスロジックを呼び出し、結果を受け取ってそれを表示するモデル。 JSP Model 2 : リクエストURIは *.jsp ではない。Strutsなら *.doのようなURIであり、フロントコンポーネントがリクエストを受け取ってビジネスロジックを呼び出して、別のビューコンポーネントに結果表示を委

＠IT 会議室 Indexリンク Windows Server Insider Insider.NET System Insider XML & SOA Linux Square Master of IP Network Java Solution Security & Trust Database Expert RFID＋IC リッチクライアント & 帳票 Server ＆ Storage Coding Edge ＠ITクラブ Cafe VB業務アプリケーション開発研究 ＠IT SpecialPR

IBMのサイトにHibernateとSpring AOPで、汎用性と型安全性を備えたDAOを作るという非常に興味深い記事を発見。これは業務アプリを作るときにいつも作成するDAOを効率よく作成する方法をまとめた記事です。通常DAOの作成って、エンティティごとに似たようなコーディングをしなくてはいけなくてひじょーに煩わしいのですが、GenericsとSpringを使うことによってこの面倒な作業から解放されます。目からウロコですね。 やってみる † エンティティなどはHibernate/Springを使ってトランザクション処理を記述するのものをそのまま流用します。 DDL create table MKINO.USER_ATTR ( USERID varchar2(100) not null, NAME varchar2(1000), primary key (USERID) ); クラス図 ま

はじめに　CJ2EEのDataAccessObjectパターンは、企業向けシステム開発で利用される非常に優れたデザインパターンです。これを利用することにより、柔軟なシステムを構築することが可能となります。有名なパターンなので、多くの方はこのパターンを使った設計／開発に携わった経験があるのではないかと思います。　しかし、DataAccessObjectパターンを使った開発は多くのクラスやインターフェイスを定義する必要があります。これは、DataAccessObjectパターンがAbstructFactoryパターンをベースとしているためです。クラスやインターフェイスの数が増えると開発コストだけでなく管理コストも増大し、開発規模が大きくなるほど影響が大きくなります。　本稿では、こうしたDataAccessObjectパターンのデメリットを回避するためのパターンを紹介します。対象読者企業システム

イントロダクション 私たちが作るアプリケーションのほとんどは、どこかで永続的なデータを扱うことになります。 そのデータの保存先は、リレーショナルデータベースやテキストファイル、他システムなどになるでしょう。 そして保存されたデータへのアクセスで使用するAPIは、保存先によって変わっていきます。 例えば、リレーショナルデータベースだとJDBCを使用します。 ファイルだとjava.ioパッケージあたりを使用したりします。 また、リレーショナルデータベースのみに焦点を当ててみても、ベンダやバージョンによって発行するSQL文を変えなければなりません。 ファイルに永続的なデータを保存していて、その保存先がデータベースに変更されたときのことを想像してください。 ビジネスロジック（業務ロジック）の中にデータアクセスにまつわるコードを書いている場合、保存先の変更が容易ではありません（同様のことが、データベ