楽々FrameworkII 体験キャンペーン中

もう1ヶ月も前のニュースだけど。
住友電工の業務アプリフレームワーク 楽々FrameworkII の無償体験版が、3月末まで入手可能だ。
http://www.sei-info.co.jp/sp/FW_taiken.html

このフレームワークはT字形ER手法と相性がいいらしい。
JavaRDBを見事に接合してみせたということで、去年の研修で正美氏が賞賛していた。
しかし!
今ダウンロードしに行ってみたら「エラーが発生しました」と言われて追い返されてしまった。


開発者のインタビューを見ると、非常に気になることを言っております。
http://www3.ric.co.jp/sol/contents/sol_0404/kikou0404.html

Javaを使ったシステム開発では、多くの企業がMVCモデルを採用している。
セミナーや雑誌等にBlue PrintsをベースとしたMVCモデルが紹介されているため、
何の疑いもなくMVCモデルを採用する企業が多いようだ。だが、新技術が登場した
背景を見極めずに採用するのは危険だ。
筆者は、MVCモデルはショッピングサイトの構築には有効であるが、基幹システム
の構築では必ずしも有効ではないと考える。

社内で利用する基幹システムでは、見栄えのみを変更することは少ない。たとえば
データ項目が増えた場合、MVCのすべてのコードを修正しなければならなくなる。
MVCを分離実装すれば開発するコード量が増え、保守性も悪化する。そのため住友
電工では、JSPEJBも利用せず、サーブレットコンテナ上で JavaBeansを利用して
いる。

いきなり主流の技術をばっさり。
でも言ってることわかる。

これまでも、画面を部品化するための様々な試みがなされたが、あまり実用的な方
法はなかった。住友電工では、この問題を「項目オブジェクト」を考案することで
解決し、画面の部品化に成功した。項目オブジェクトはデータ項目をオブジェクト
化したもので、データラベルや桁数、入力形式等を保持している。

これはまあよくある話だが、次。

また、DBの入出力も簡単に部品化できる。DBのテーブルに対応したラッパークラス
を用意すればよい。
ポイントはgetter/setter を実装しない点だ。getEmpNo()やgetName()等のメ
ソッドを実装すれば、そのメソッドを呼び出すプログラムは汎用的に利用できなく
なる。列名と値のペアを複数保持できる汎用的なオブジェクトを利用する方がよい。

これらの画面部品とDBの入出力部品を使って、データを照会・登録・変更・削除す
るプログラムを開発すれば、汎用性の高いプログラムを作成できる。プログラム中
に受注番号や社員番号といった固有の名称を埋め込まなければ、このプログラム自
体がソフトウエア部品となる。

住友電工ではこの部品を「業務用コンポーネント」と呼ぶ。これを利用すれば、
従業員の登録にも部署の登録にも同じバイナリ部品を使い、Javaのコードを
一切書かずに実装できる。

面白い。使ってみたい...