昨日の記事に、はてなスターをいただきました。まさか見ている人がいるとは・・。自分用のつもりでした。
都合により週末は書けないので、次は来週の火曜日の予定です。
カッコは私が補足したほうがわかりやすいと感じて追加したものです。
また、後から内容を訂正する場合があります。まだ理解できていない部分も多いです。
Table Data Gateway(2)
Table Data Gateway
When to Use it
- このパターンはデータベースを扱う上で最も単純である
- Domain Modelパターンでは小規模で使用する。Data Mapperのほうがよりデータベースと分離することができる。
- Table Moduleパターンで、Record Setを作る際にはうまく働く。
- Transaction Scripts パターンにも合う
- Data MapperがDatabaseからデータを取るときに、Table Data Gatewayを経由して使用することがある。手作業で関連付けるのではなく、メタデータを使って（自動的に）関連付けるのであればとても効果的である。
- Table Data GatewayはDatabaseへのアクセスをカプセル化しているので、更新時にSQLとストアード・プロシージャーの両方を（透過的に）使うことができる
Table Data Gateway(1)
Data Source Architectural Patterns
Table Data Gateway
- ひとつのインスタンスがテーブルの全ての行を制御する
- 一つのテーブルやビューに対するselectやupdate, deleteなどをすべて（1つのクラスに）集約する
How it works
- selectに対応するfindメソッドを条件により複数作る
- update, delete, insertといった操作に関するメソッドも作る
- 通常は各メソッドはステートレス（状態を持たない）
- 問題はどのようにしてクエリの結果を返すか。マップのような構造に詰めて返すこともできるが、（データベースの項目とマップに格納されるキーとの関係は）コンパイルなどでもチェックできず、誤りやすい。Data Transfer Objectパターンを使うのがよい選択肢となる。SQLの結果としてのRecord Setをそのまま返すこともできるが、データベースに特化してしまい、インターフェースをファイルなど他のものに置き換えにくくなるかもしれない。
- 実際のデータベースのテーブルごとに（=正規化したあとなど、RDBとして格納に適した形で）つくるのではなく、ビューごとに（＝実際に使用する形で）、Table Data Gatewayを作ることで、データベースとの結合性を低くすることができる
- ビューベースのTable Data Gatewayにupdateなどの振る舞いをもたせるときは、その元になっている実際のテーブルに対する更新を行う。それができるのなら、Table Data Gatewayはよいテクニックとなる。
- Domain Modelを使用している場合は、Table Data Gatewayが適切なDomain Objectを返してくれる。しかし、両方向に依存性がある（＝変更があれば、両方に影響する）。
SIerがなぜ、こうなってしまうのか
ほぼ、1年ぶりに日記かな。
そもそもSIとは要件定義から保守までを一括請負するという意味であって、例えば、いわゆるWeb系エンジニアがそれの対極かというと、どうも違うような気がする。SIでもWeb系の仕事をするだろうし、いわゆるWeb系エンジニアがコンサルティングだけを請負ったり、プログラミングだけを請け負ったりするわけでもない。
では、いわゆるWeb系エンジニアとの違いは何か？私はこう思う。
他社向けのシステムを、請負契約などに基づいて構築するか、社内のエンジニアとして自社のためのシステムを構築するか
こういう意味では実はSierの中でも、社内システムやパッケージ開発などを行っているセクションはWeb系の開発のように新しい技術を受け入れやすいはずだ。実際は違うかもしれないが。
他社向けのシステムを構築する場合、契約が非常に重要になる。これはそう簡単に変えられるものではない。契約を守るために必要なものは、納期・予算・品質（いわゆるQCD）である。一方、社内向けのシステムであれば、システムの構築自体が契約によって定められているわけではない。ある程度の調整はできる。
契約を履行するうえで、新しい技術を導入して大きな失敗を生むわけにはいかない。このため、できる限り保守的な解決を図ろうとする。
また、他社向けのシステムが大規模な場合は、様々な下請け会社を含めて大量の人員を使ってQCDをコントロールするため、過剰なルール主義に陥りやすい。できる限り作業する人に考えさせないようにする。これにより、同質のものを大量に製造することができる。とにかく想定の範囲内にプロジェクトをコントロールすることが最も重要な関心事であって、この匿名日記の作者のようなルール以外のことをしようとすると、はじかれるのだ。
よって、SIはこうなりやすい。
もう少し幸せに働くためには、
- 要件をあいまいにしない。何を作るのかを明確にする。固定コスト・納期の厳守が顧客のニーズであるなら、要件の厳密化は譲れないはずだ。（アジャイル開発等を受け入れてくれるならともかくとして）
- ルール作りは重要だが、ルールの改良を行うのも重要
- 初期の学習コストを投資して、効率性を改善するための新技術の投入を行う
SIというビジネスがなくなるとき、それはきっと、顧客企業がシステム会社に丸投げするのではなく、自製し始めたときだと思う。
テスト
テスト
テストで書いてみました。
どうかなぁ。
順位戦とAWAKEに挑戦
１日見ていました。時間があっという間になくなってく。
