<< Smart UI が優れている? | main | Smart UI なら Smart UI らしく >>

Smart UI から抜け出すきっかけ

ドメイン駆動設計 (DDD) のアンチパターン Smart UI の実践の話しの続き。

画面単位に担当わけして、ばらばらに作った結果、あちこちで不整合が発生して、バグだらけで終始が付かない状態から、プロジェクトの再建に取り組む。

このときは、

・ドメイン駆動設計
・モデル駆動設計
・オブジェクト指向設計
....

なんていう高尚な話しではないです。

なにが、大量のバグ退治に有効か? この一点で考えた。

画面間の連携の不整合は、データ不整合として発覚する。
まずは、データベースアクセスまわりを重点に取り組むことにした。

バグだけではなく、データ量が増えるにつれ、深刻なSQL性能問題も顕在化。問合せが、30分待ったあげく、タイムアウトが発生。この点でも、データアクセスまわりが緊急の問題。

StringBuilder で SQL 組立方式との戦い


コードのかなりの量が、StringBuilder で SQL 文を組み立てて、実行する箇所。
また、SQL の問合せ結果を格納するオブジェクトも、開発者によって、ばらばら。
.NET フレームワーク提供のマクロなオブジェクトとメソッドを使う開発者もいれば、できるだけ、SQL のプリミティブな操作と、問合せ結果の低レベルの直接ハンドリングを使う開発者もいる状態。

問題の起きているテーブルに対する CRUD の実装箇所を調べようとしても、そもそも、どこで何をやっているか、見通しが極端に悪い。

とにかく、SQL生成と、データベースアクセスまわりを整理したかった。
データベースのアクセス方式も統一したかった。

iBatis.NET で SQL を整理する


採用したフレームワークが、iBatis.NET。
SQL 文をXMLファイルに定義する方式の O-R マッピングツール。

まず、このツールを使って、
・SQL 文を XML ファイルで外だし
・SELECT の問合せ結果を格納のするオブジェクト(データオブジェクト)を新規に設計・実装
・SQL 文にパラメータを渡すためのパラメータオブジェクトを新規に設計・実装
をゴリゴリと行った。

この結果、データベースアクセスまわりの見通しは格段に良くなった。
どこで、どのテーブルに、どのようにアクセスしているか、調査や判断がだいぶ楽になった。

また、SringBuilder で、SQL を組立ていたコードは、かなり冗長だったし、そもそも誤ったコードもかなり見つかった。(コピー&ペーストで量産したため)

StringBuilder で動的に組み立てているコードを読んでもすぐわからなかったが、SQL部分だけを、XML ファイルに抜き出すと、一目瞭然になることが多かった。

データオブジェクト


iBatis の問合せ結果は、オブジェクトにマッピングする方式。
だから、データの入れ物として、例えば、会員(レコード)オブジェクト、申込(レコード)オブジェクトとかを作成した。

このときは、ドメインオブジェクトという意識はまったくなく、ただのデータの入れ物。
後になってみれば、これが、ドメイン駆動設計、ドメイン層の分離にとても役に立ったわけだが、このときは、そんなこと、考えもしなかった。

パラメータオブジェクト


それまでは、データアクセス用のメソッドを呼び出すときのパラメータに、Pageオブジェクトをまるごと渡しています。
Pageオブジェクトであれば、関連するデータは、すべて持っているので、とりあえず、これを渡しておけば、どうにでもなる。

これを、問合せごとに必要なパラメータだけに絞った「パラメータ・オブジェクト」を作って、Pageオブジェクトでのパラメータ渡しは厳禁とした。

この結果、問合せに何を渡して、何を実行しているのかが、単純に理解できるようになった。

Pageオブジェクトをまるごと渡して、StingBuilder で、 SQL を動的に作っているコードとの見通しの違いは、ほんと雲泥の差だった。

バグつぶしと性能向上


iBatis.NET フレームワークと使うために、
・SQLMap( SQL文のXML記述)
・(結果を入れる)データオブジェクト
・(検索条件の)パラメータオブジェクト
の3点セットをいっしょうけんめい作った。

結果、データ不整合のバグは、だいぶ減らすことができた。

まず、DB制約と、整合性チェックSQLで、深刻な問題箇所を発見する。

一意性の不整合とか、参照整合性の違反、必須、重要なデータ形式やデータ範囲の違反、などは、まず、データベース側に制約を作成した。

深刻な不整合バグは、データ内容を検証するための簡単なSQLスクリプトを用意し、定期的に実行して、発生直後に見つけるようにした。

ここで見つかった箇所を中心に、iBatis.NET でデータアクセスコードを書き直すことに注力。

大半は、わかってみれば、単純なデータ不整合だったので、とにかく、SQL文を整理して、地道に修正することで、ある程度、データ不整合が落ち着いてきた。

また、チューニングポイントも見つけやすくなった。
単純に、インデックスの張り忘れ、張り間違いとかも多かった。
結合条件なしに、強引に値範囲などで絞り込んでいた箇所も多く、これは、結合をちゃんとやるだけで、ずいぶん改善した。

まあ、現実的には、簡単には直せないバグと性能問題が残り、最後まで苦しめられましたが、全体としては、iBatis.NET で、SQL文・データアクセスを分離する効果は抜群だった。

ちょっぴり Smart UI が改善


画面からデータアクセスまで、担当者別に完全に縦割りしていた。

でも、iBatis で、SQL 文を整理することで、関連する情報を扱う画面では、共通のSQL文を利用する範囲が少しずつ増えてきた。

Smart UI の問題は、同じテーブルを、同じ目的でアクセスするのに、画面ごとに重複して記述すること。

だから、画面Aでの検索結果と、画面Bの検索結果が一致しない、とかが平気で起きていた。

この不整合がなくなったのは、ユーザから見れば、大進歩。(あたりまえの状態になっただけで喜んでもらえるのは、情けないというか、ありがたいというか....)

次のステップ



こうやって、深刻なバグや性能問題が、ある程度、おさまると、バグ修正へのプレッシャも緩和し、じっくりと、より本格的な改良に手をつける余力がでてきた。

まだまだ、Smart UI から抜け出す旅は続きます。

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
  12345
6789101112
13141516171819
20212223242526
2728293031  
<< August 2017 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
  • 番号より名前。 ニーモニックコードより名前。 【パターン】
    師子乃 (03/10)
  • Smart UI が優れている?
    masuda220 (03/10)
  • Smart UI が優れている?
    kagehiens (03/09)
  • オブジェクト指向プログラミングの教え方?
    masuda220 (12/05)
  • オブジェクト指向プログラミングの教え方?
    ZACKY (12/04)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    kompiro (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    JHashimoto (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (02/28)
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM