- PR -

バッチをオブジェクト指向で設計

«前のページへ 1|2|3 次のページへ»
投稿者投稿内容
ＹＯＵ＠ＩＴ
ぬし
会議室デビュー日: 2002/03/29
投稿数: 284
お住まい・勤務地: 大阪
投稿日時: 2004-02-26 19:47

Javaでバッチ処理をフレームワーク化...私個人も基本的にはその方針を支持
するんですけど、手続き型に実装した場合と比べて処理速度が気になります。

特に大量のデータを扱うような場合は、些細なオブジェクト生成コストも
ちりも積もれば...とやらで結構大きなコストになるのではないかと思います。

とは言え、同じ処理をOOと手続き型で実装して比べたわけでもないので、
実際どれほど差がでるかはわからないのですが...

体験談をお持ちの方がいらっしゃいましたらご意見を伺いたいです。

m.ku
大ベテラン
会議室デビュー日: 2002/09/15
投稿数: 184
投稿日時: 2004-02-26 20:12
少し古いですが、こういう記事がありますね。
「オブジェクト指向のバッチ処理への適用とJavaの可能性」
http://hp.vector.co.jp/authors/VA015862/javabtch.html

当時からいずれの処理系も進化していますので
現在の指標としては向きませんが、考え方や比較方法は
参考になるかと思います。
CHN
ぬし
会議室デビュー日: 2002/03/07
投稿数: 382
投稿日時: 2004-02-26 20:19
引用:

サさんの書き込み (2004-02-26 11:52) より:
引用:

永井和彦さんの書き込み (2004-02-26 11:31) より:
抽象化をきっちり行えば行っただけの恩恵がある「かも」知れませんが、あくまで潜在的な要素ですので、最終的には自分のバランス感覚と相談して「適当なレベル」までで止めておく方が無難かと思います。

"バランス感覚"って大事ですよね。

そういえば、ラクダ本にこんな一節がありました。
引用:

私たちは、本来ならより高いレベルの抽象化を導入すべき局面で、カット&ペーストで済ませてしまうという罠にしばしば陥りがちである。
また、これとは正反対の極端に走り、本来ならカット&ペーストで済ませるべきところを、高レベルの抽象化の山をどんどん築き上げてしまう人たちもいる。

耳が痛いですなぁ。

ついでにもう一つラクダ本から。僕の好きな言葉を。
引用:

オブジェクト指向デザインは、それが意味のある場合に使い、そうでない場合には避けること。

至言。

[ メッセージ編集済み 編集者: サ 編集日時 2004-02-26 11:56 ]

分かっていても、ついやってしまいますね〜。
->力不足ですね。自分もそうです。
_________________
シュン
ぬし
会議室デビュー日: 2004/01/06
投稿数: 328
お住まい・勤務地: 東京都
投稿日時: 2004-02-27 10:50
Antを、話題の「バッチ処理用フレームワーク」としてそのまま使えそうな気がした
のですが。

1.各種ロジック、入出力(ファイル上のデータ←→Javaオブジェクト交換)などの
処理を記述するオブジェクトを、Ant Taskとして実装する。
2.Build.xmlでバッチ処理の内容(Ant Taskの呼び出し順序)を記述。

あるいは、フレームワークを自作する場合、Antの構成を参考にするというのも良い
のではないでしょうか。

以前、業務システムのバッチ処理のような規模の大きいものではありませんが、似た
ようなものをかつて一度作ったことが有りまして･･･スクリプト言語を自作するのは
面倒だったので、Antのやり方(XMLでスクリプトを記述する)をそのまま真似させて
もらいました。
しょむ
ぬし
会議室デビュー日: 2001/09/06
投稿数: 430
投稿日時: 2004-02-27 15:14
バッチ処理の汎用フレームワークは、非同期型並列バッチ処理まで対象を広げると便利です。

- 複数のバッチつっこみ側アプリが、ひとつのジョブキューにジョブをつっこむ
- 複数のジョブサーバがジョブキューを監視
　自分がジョブ処理可能であれば処理開始、ジョブ処理状況を適宜更新
　ジョブが終了したらジョブ結果をジョブ結果キューにつっこむ
- バッチつっこみ側アプリはジョブ処理状況を見て、
　終了していれば結果キューから結果取得

典型的なWebアプリでこれが有用なのは、特定種類のサーバで一度にひとつしかジョブを実行できない場合に(Word/Excel/PDFの生成、画像加工、並列印刷などなど)、これらの処理を並列化したいときです。

エラーリカバリ処理とか、けっこう面倒なもんですよ。
ジョブやキュー、エラー、バッチ入出力の部分など、OOPによる抽象化には向いているかと。

こういう定番のフレームワーク、COBOLにもあるでしょ？
taku
ぬし
会議室デビュー日: 2002/11/12
投稿数: 918
お住まい・勤務地: 墨田区→中野区
投稿日時: 2004-02-27 15:39
引用:

しょむさんの書き込み (2004-02-27 15:14) より:
こういう定番のフレームワーク、COBOLにもあるでしょ？

　汎用機時代（３年ちょっと前）にフレームワークという言葉自体を、
耳にしたことが無いですね・・・。
unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)
投稿日時: 2004-02-27 15:49
unibon です。こんにちわ。

ジョブ管理みたいな感じでしょうか。凝るとグリッドコンピューティングになってしまいそうですね。

システム名だけ思いつきました。
Pragmatical Execution and Repeatable Launcher
頭文字だけを取り出して略すと...
おばけ
ぬし
会議室デビュー日: 2002/11/14
投稿数: 609
お住まい・勤務地: 東京都江東区
投稿日時: 2004-02-27 16:32
引用:

Pragmatical Execution and Repeatable Launcher
頭文字だけを取り出して略すと...

本家は
Practical Extraction and Reporting Language
でしたっけ？
«前のページへ 1|2|3 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）