Why I hate XXFW
I want to say a little more about long-sql problem.Since I wrote it up in Japanese, I will paste it here.
長いSQL利用するメリットとデメリットが以下のものがあると考えられます。
メリット：
1. コード変更の影響範囲が小さい。 各プログラムの中に、同じ処理をやっているにもかかわらず、 利用するデータを毎回一番低い位置となる生のDBから取り出している。 一本のプログラムを修正しても、基本的には他のプログラムに影響しない。2. DB利用の効率がいい。 できるだけ多くの作業はひとつのSQLに書くと、 DBとのやり取りの時間が短くなって、コード全体的な効率がいい。
デメリット
1.開発は辛い。 DBの上に、抽象的なカプセル化したオブジェクトはないので、 どんなデータが必要になっても、一番下のDBからSQLで取得しないといけない。 そこで、ビジネスロジックにおいて、 各テープルの間の関連と関連の詳しい内容まですべて理解しないといけない。 仮にあるデータを取得するために、10個のテーブルをJOINする必要がある場合、 このデータを使う都度、この10個のテープルをJOINするSQLを書かなきゃいけない。 このような細かいビジネスロジックを理解する難しさと 大量の重複なソースコードを書く大変さは辛いと思います。2.メンテナンスはやりにくい。 「10個以上のテーブルで関連して、異なる目的のデータを一箇所で取得し、 それにデータの取得だけではなく、画面表示用のデータ構造まで作っている」 このような膨大な100行以上のSQLを細かく理解しないといけない。 これは長いSQLを利用する場合のメンテナンス作業の現実です。 このようなコードを理解するには、 システムの仕様をすべて理解できている方は少し時間がかかる、 SQLの理解能力があって、積極的にシステムの仕様を理解しようという方は結構時間掛かる、 そうでないと、ほぼ理解できないと思います。 言い換えると、仕事でなければ、100行以上のSQLを見ようとする人は多分いないと思います。 それに、もともと重複で書かれたSQLのコードはあちこち散在しているので、 一本のプログラムにSQLを修正して問題なしで終わったら、 今度メンテナンスする方は、 なんで同じデータなのに、全然異なる所から情報をとっているという疑問も生じやすい。
では、どうすればいいですか？と更に考えると、やはりDBの上に、ビジネスロジックをカプセル化した抽象的なものが必要だと思います。現在流行っているActiveRecordのようなORMのレベルに達しなくても、少なくとも最低限のオブジェクト指向の概念が必要と思います。
XXFWはJavaを利用して、MVC構造中のViewとControllerの部分を結構カプセル化されていて、便利になっていると考えています。
しかし、ビジネスロジックと一番関連の緊密のモデルの部分について、現実なロジックを解決するために出てきたオブジェクト指向の概念はほとんど利用していなくて、惜しいいと思います。
例で簡単に言いますと、ある受注の一番目の明細商品のお客様側の商品コードを取りたい時、
今のやり方だと、
select 商品対応表.お客様商品コードfrom 受注HDRinner join 受注DTL on 受注DTL.受注HDR番号 = 受注HDR.受注HDR番号inner join 関連会社 on 関連会社.関連会社コード = 受注HDR.関連会社コードleft outter join 商品対応表 on 商品対応表.商品コード = 受注DTL.商品コード and 商品対応表.関連会社番号 = 関連会社.関連会社番号where 受注HDR.受注HDR番号 = ?order by 受注DTL.行番号limit 1
オブジェクト指向の方法だと、
受注HDR.一番目の受注DTL.お客様商品コード
一目瞭然、SEにとっても、PGにとっても、後続のメンテナンスの方にとっても、オブジェクト指向の方法を使うほうがやりやすいでしょう。
では、オブジェクト指向の方法を使うと、影響範囲と実行効率の問題はどうなるでしょう？
1.影響範囲の問題 オブジェクト指向を利用すると、自動テストできるので、 更に、TDD(Test Driven Development)の手法を利用すれば、 影響範囲の問題がほぼなくなるだけではなく、 もっと効率的に（画面で確認するという伝統的なテスト手法はいらなくなる）、 もっと堅実のコードを作れると思います。2.実行効率の問題 DBにとって、一つ大きいSQLと分割したいくつかのSQLの実行時間の差異は非常に小さいので、 よぽど重い処理で無い限り、ユーザーはこの時間差を感じられないと思います。 その反面、メンテナンスの作業は何時間から何分間に変わるかもしれないです。 さらに、より新しいORMを利用すれば、 オブジェクト指向の方法も上記のような複雑のデータ取得に、 一つのSQLしか発行しないので、根本的に実行効率の問題解決できると思います。
プログラムを作り上げるという視点から見ると、KISS (Keep it simple and stupid) と DRY (Don’t repeat yourself)の考え方のもとで、オブジェクト指向を利用したほうが絶対開発は便利になる。
ビジネスロジックのシステムを構築するという視点から見ると、階層的にビジネスの概念をカプセル化し、その中の関連を内部に隠すれば、設計上もしやすくなるではないかと思います。