トップページ⇒tech
1001コメント376KB

国産DIコンテナSeasarとくーす その3

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさんNGNG
一部で話題になっている国産オープンソースDIコンテナSeasar V2(略してS2)。
ってどうよ?みんなもう使ってるの?
使用経験とか、実戦配備情報とか、つかえねーよボケ、とかいろいろ書いてね。

あと、開発プロセス「くーす」の話題もこちらでどうぞ。


本家 seasar.org
http://www.seasar.org/

Seasar Projectグループ
http://seasarproject.g.hatena.ne.jp/

ひがやすをのここだけの話
http://d.hatena.ne.jp/higayasuo/


前スレ
その1 http://pc5.2ch.net/test/read.cgi/tech/1092044210/
その2 http://pc5.2ch.net/test/read.cgi/tech/1098885253/


関連スレ(なのか?)

Java Spring Frameworkを語るスレ
http://pc5.2ch.net/test/read.cgi/tech/1077465099/
0400デフォルトの名無しさんNGNG
>ひがさんにOOSEを読んでみて欲しいな。

ひがさんが問題としていることは、OOSEでも取り上げられているから。
0401デフォルトの名無しさんNGNG
>>398 すっげーおおざっぱには、それでよい。
0402デフォルトの名無しさんNGNG
初心者が1ヶ月読まないとそこにたどりつけないドキュメント。
0403デフォルトの名無しさんNGNG
http://d.hatena.ne.jp/higayasuo/20041228#1104228438
>その原因は、過度なデータ中心のクラス設計にあると私は考えています。
>データと振る舞いを1つのクラスにまとめるのは、自然なことですが、
>あるデータを使う機能をすべて1つにまとめると役割持ちすぎなクラスに
>なりやすいと考えています。

OOSEのP120~P129はその答えとなりませんか?
0404デフォルトの名無しさんNGNG
>>402
ちょっとコードを書けばすぐにわかると思うんだけどね。
最近はドキュメント読んだだけで済ませようとする人が
多いのでびっくりだ。
0405デフォルトの名無しさんNGNG
>その原因は、過度なデータ中心のクラス設計にあると私は考えています。
>データと振る舞いを1つのクラスにまとめるのは、自然なことですが、
>あるデータを使う機能をすべて1つにまとめると役割持ちすぎなクラスに
>なりやすいと考えています。業務アプリケーションなどはとくそうで、
>直接関係のない機能が1つのエンティティに押し込まれやすくなります。

そうなった場合に適宜リファクタリングしてやれば解決する問題だと考えます。

>また、複数のデータにまたがるような機能は、そもそも適したクラスに
>振る舞いを割り当てるのが難しくなります。

複数のデータにまたがるような機能が全てそうだとは言いませんが、どのドメインオブジェクトへも割り当てがたい責務はコントローラクラスへ割り当てれば良い、と古のOOSEに記されています。そのことには異存ありません。
# UnifiedProcessは全く追っていないので、もうobsoleteなのかもしれませんが

データと振る舞いをひとつのクラスにまとめる。責務が多くなりすぎたらクラスを分割してやる。振る舞いを割り当てるのに適したクラスが無い場合はコントローラクラスとする。これでも駄目なのでしょうか?
0406デフォルトの名無しさんNGNG
>>404
読む人のせいにする筆者
0407401NGNG
>>402
最新版のドキュメントは、昔と較べると段違いに充実していると思う。
# S2JSFのドキュメントがないのは、正式公開前だし、しかたないだろう。
まさたかさんの入門記事も参考になる。
http://d.hatena.ne.jp/masataka_k/searchdiary?of=15&word=%2a%5bseasar%2dtutorial%5d
(もしかすると若干記述が古くてハマるかもしれん)。

俺はS2財団の人ではない。単なるファンだ。
だが、煽りが出たらごめん。> やすを氏ほか。
あと技術的な話をしているところを、側面的なネタで汚してすまん。
0408デフォルトの名無しさんNGNG
>>401
そうですか・・・・・・やっと、やっとここまで辿り着きました(;´д⊂ヽヒックヒック

>>404
ぶっちゃけその通りです>ドキュメント読んだだけで済ませようと
「Seasar = フレームワーク」と勘違いして、「クラスを切り替えられるのは分かったから、それ
で最終的にはどうなるんだ?」という明後日な視点でドキュメントを読み続けてました。

髭剃りを他の何かだと頑なに信じ込んでしまってる人が、説明書を見ながら「髭が剃れるのは
分かったから、最終的にどうなるんだ?」と途方に暮れてる姿を想像してもらえれば近いので
はないかと・・・・・・
勿論、結論は「だから髭が剃れるんだよ」というものなんですが、見てる方向が違うと辿り着け
ないんですね、これが_| ̄|○|||

最後に、とりあえず現在のところドキュメントに不満はありません。
目は何も見てはいない、見ているのは脳。という言葉をちょっぴり実感した年末でしたw
0409デフォルトの名無しさんNGNG
>>405
>複数のデータにまたがるような機能が全てそうだとは言いませんが、
>どのドメインオブジェクトへも割り当てがたい責務はコントローラクラスへ
>割り当てれば良い、と古のOOSEに記されています。
>そのことには異存ありません。
> # UnifiedProcessは全く追っていないので、もうobsoleteなのかもしれませんが

余談ですが、昨今の、ロバストネス分析で導出されたコントロールクラスは設計モデルでそのままストレートにクラス化すべし、という風潮はあまり好きになれないです。
某オブジェクト指向本も読んでみたんですが、ドメインモデル貧血症推奨な感じで、なんだか。

RUPの人もICONIXの人も、分析段階でのコントローラクラスの責務はバウンダリかエンティティに割り当てる、もしくはコントローラ自体をクラス化する、と言ってるように思うんだが。
というか、スリーアミーゴはICONIXの人よりもきつい言い方をしてて

「コントロールクラスを実現するのに別々の設計クラスを用意するのは
適切ではない場合がある。むしろ、関連するバウンダリやエンティティを
実現する設計クラスと同じものでコントロールクラスを実現したほうが良い」

と言ってるのだが。
0410デフォルトの名無しさんNGNG
S2のドキュメントは昔に比べたらめっちゃ充実ですね。
S2Daoもここのところリリースが多かったですが、追加したあのテーションとかも
ちゃんとドキュメントに反映されてるし。
0411デフォルトの名無しさんNGNG
>>409
>「コントロールクラスを実現するのに別々の設計クラスを用意するのは
> 適切ではない場合がある。むしろ、関連するバウンダリやエンティティを
> 実現する設計クラスと同じものでコントロールクラスを実現したほうが良い」

原文を知らないので良くわからないのだけど、それってStrutsで言えば、
Action内で直接エンティティにアクセスするってことかな?
0412デフォルトの名無しさんNGNG
相変わらずドキュメントネタしか突っ込めない>>406
0413デフォルトの名無しさんNGNG
どうでもいいが、S2JSFだけ早くリリース汁
0414デフォルトの名無しさんNGNG
さっぱり話についていけないので、とりあえずPoEAAを読み始めた。
0415デフォルトの名無しさんNGNG
ひがし
> blogに、これまでのオブジェクト指向の批判を書くのは、
> 私にとってはものすごくリスクの高いことです。なにを
> 言われてもおかしくないですから。現にいろいろ言われ
> ているわけですが、それでもあえて書いているのは、こ
> れまでのオブジェクト指向がなぜうまくいっていないの
> かを考え直すきっかけになればと思っているからなのです。

「これまでのオブジェクト指向」の定義と
「うまくいっていない」とする根拠を明確に示さないとただの
戯言.今までにない自分が始めて見つけた設計方法と認識して
いるならば非常に痛い.自らの失敗経験や知りえる範囲での失
敗を踏まえた程度ではないのか.
0416デフォルトの名無しさんNGNG
  ↑
OO厨キター!
0417デフォルトの名無しさんNGNG
>>415
同じコトをファウラータソにも突っ込んでやってくれ。
http://www.nri-aitd.com/tips/image/g-patern_4.gif
は根拠が薄弱すぎるとひが氏なんかよりも罪深いぞ。
特に線の交差するところは重要じゃないか?
SQLのあまりにもな例といい結構ファウラータソも危ういと感じる。
0418デフォルトの名無しさんNGNG
>>417

いいんだけど、ファイル名が怪しい
0419デフォルトの名無しさんNGNG
もうね、GoF以上にソフトウェア開発の実装におけるパターン化をやろうとしても、
ムリだってことがハッキリしたと思う。

これ以上ソフトウェア開発を効率化しようとするなら、
例えば業務会計ソフトなら、会計ソフトをプラグインで柔軟に変更可能にするとか、
そのAPIをソースコードごと公開するとか、
そういう、実装が伴ったものになると思う。
EJBのようなアプリケーション固有の実装を伴わないフレームワークは必要無い。
0420デフォルトの名無しさんNGNG
Enterprise Applicationは個々に異なる、という前提があるので、残念。
0421デフォルトの名無しさんNGNG
>>420
わからん
前提があるからどうなんだ?
0422デフォルトの名無しさんNGNG
>>419
DI + II まだー?
0423デフォルトの名無しさんNGNG
実装を共有しようとするのは現実的でなく、
フレームワークやパターンや開発手法を共有するしかない、ということ
0424デフォルトの名無しさんNGNG
>>423
PhotoshopやEclipseはどうなんだ?
プラグイン毎にソフト作り直すのが現実的なのだろうか

業務ソフトだってその考え方をもっと進めなきゃいかんと俺は思う
0425デフォルトの名無しさんNGNG
現実には、業務ソフトにまともなプラグイン機構を持ったソフトは
未だ存在しないから、せめてムダなフレームワークを使わず
ただシンプルに作り抜くことが、今できることなんだろうと思うけどね。
0426デフォルトの名無しさんNGNG
>>417
原文読め
自分がネタにマジレスってことに気付くから
0427デフォルトの名無しさんNGNG
>>424
ベースを作ればあとは付加機能でしかないという分野以外で、同じようにプラグインの仕組みを考えるのはナンセンスだと思うが。
やっても意味がないという結論がでるようなことがらについて考えを進めても意味がなさげ。
0428デフォルトの名無しさんNGNG
ひがさんのblog
> 手を変え、品を変え、オブジェクト指向は説明されてきましたが、情況はそれほど好転しているように思えません。

続く文章も、手を変え品を変えたオブジェクト指向の説明に見えるので、状況がそれほど好転しない気がする。
0429デフォルトの名無しさんNGNG
>>427

確かに、同じようなプラグインの仕組みは、やるだけムダなのかもしれないし
けど、うまく設計すれば、うまくいくかもしれない。
設計は難しいものになるだろうけど、チャレンジしてほしいけどね。誰かに。

S2やEJBは何の解決にもならないのは確か。
ならシンプルな技術基盤で作りたいね。
Javaを使ったウェブプログラミングがめんどくさいからいろんなフレームワーク
がでているわけで、なら別のプラットフォームを選ぶのがいいと漏れは結論した。
結果を出せるのはスクリプト言語だなと思ってる。
0430デフォルトの名無しさんNGNG
>>429
>設計は難しいものになるだろうけど、チャレンジしてほしいけどね。誰かに。
なんだよ、他人事かよ・・
0431デフォルトの名無しさんNGNG
業務というもの自体がPlugableじゃないからね。
何か新しい業務が埋め込まれたら、既存の業務に必ず変化があるし。

Plugableにするために工程とかプログラムの部分部分がちょっとでも複雑になるなら、普通にシンプルに作って、わかりやすく変更できるようにした方がよさげ。
0432デフォルトの名無しさんNGNG
>>431

プラグイン機構を持ったソフトを売るか、それ自体を使ったソリューションビジネスを始めようってんでも
ない限り、そういう先を読んだ拡張性を重視するのは、危険だな。
You aren't gonna need itの原則だ。
まさに、普通にシンプルがよさげ。


まぁ、プラグイン機構を持つのに向いている分野もあれば、向いてない分野もあると思う。
向いている分野も結構あると思うんだけどね。
0433デフォルトの名無しさんNGNG
たとえば、金融商品を扱うとかで、商品自体がデータ構造とアルゴリズムを持つような場合は、取り扱い商品をモジュールとして追加できるようにするというのはアリだろうね。
0434デフォルトの名無しさんNGNG
>>429はDIスレに帰れ。

皆さんネタ厨に餌を与えないでください。
0435デフォルトの名無しさんNGNG
>>434

多分、無知だからだと思うんだ。
だから、スクリプト言語によるウェブシステム構築よりSeaserで作ったほうがイイ点、
勝ってる点を教えてください。
0436デフォルトの名無しさんNGNG
>>435
規模とか開発の人数によるよ。
スクリプト言語よりもJava+Seasarの方が、均質なコードを書くための労力が少ない。
均質なコードを書く労力が問題なければ、スクリプト言語でいいと思う。
0437デフォルトの名無しさんNGNG
マジにスクリプトのほうがコンパイル言語より基幹につかうに向いていると思ってるなら、死んだほうがいいな。
0438デフォルトの名無しさんNGNG
基幹っていっても、でかい基幹ばかりじゃないからなぁ。
0439デフォルトの名無しさんNGNG
5年くらい前なら、Javaで基幹系? 正気ですか? 医者よびましょうか? というような
感じだったような。今はどうであれ、先の事はわからない。
0440デフォルトの名無しさんNGNG
そのときでも、実務では使えないだけで実績がでてきたら使いたいというのがあったわけだけど、スクリプト言語の場合は・・・
0441デフォルトの名無しさんNGNG
>437
>440

だから、それはなぜかを示してほしい
0442デフォルトの名無しさんNGNG
素人には基幹系は無理。
Javaプログラマは素人。
よって、Javaプログラマには基幹系は無理。
以上。
0443デフォルトの名無しさんNGNG
>442
二番目が根拠無し
0444デフォルトの名無しさんNGNG
明らかにスレ違い。>スクリプト言語と業務アプリ
別のとこでやってくれ。
0445デフォルトの名無しさんNGNG
ここの話の流れだと、スクリプト言語とJava+Seasarを対比して、Seasarの特徴を知るという感じでもないね。
0446デフォルトの名無しさんNGNG
>>436

均質っていうけどなぁ、
均質にするのは方法論であって。
その方法論を実現するのには、コンパイルに依存しない
弱い結合が必要だっていうから、Seaserがあるわけでしょ。
コンパイル依存をなくしたいと思って行きつくところは、
動的なスクリプト言語ってことにならないだろうか?

それに、O/Rマッピングとか、ソフトウェアを複雑にする要因を
増やしてもしょうがないと思う。
0447デフォルトの名無しさんNGNG
>>446
実装との依存性はなくしたいだけど、
仕様(interface)との関係は明確にしたい。
仕様に合致してるかどうかはコンパイラにチェックして欲しい。

O/Rマッピングは関係無いと思うけど。
S2Daoの話なら別に複雑じゃないよ。
0448デフォルトの名無しさんNGNG
>>447

しかし、キャスト要らずのコードにするために、
あのdiで書かれた設定ファイルが必要になるわけで、
どっちにしろ動かしてみるまで分からないのは一緒だと
思うのだけど、どうだろうか。

それに、あのdiファイルってすごく冗長で書くの辛いしツール要るしで、
なんか本末転倒感が強い。
0449デフォルトの名無しさんNGNG
キャスト要らずってのは、間違いかな。どっちにしろ要るんだから。
0450デフォルトの名無しさんNGNG
業務ソフトは必ず一から作り直さないとダメ、
プラグイン機構を持ってもしょうがない、
ってな話あるけど、必ずしも、
そうでもない気がする。
ERPソフトの全てがネタだとは思わないし、
適切なインターフェースさえ定義して
そのインターフェースAPIの意図を素早く読み取って
プラグイン作る人さえそろえば、
少ない労力で結果として効果の高いソフトが作れると思うよ。
0451デフォルトの名無しさんNGNG
確かにコンフィグ系コンテナって設定ファイルが冗長だよな。
S2は特にそうだ。
0452446,448,449,450 ◆iKwMOjCT4s NGNG
そもそも、コンテナとは何か?
言語本来備わっている名前空間機能ではいかんのか?
と思うわけだな
0453デフォルトの名無しさんNGNG
モチツケ。
0454デフォルトの名無しさんNGNG
>>450

> 適切なインターフェースさえ定義して
> そのインターフェースAPIの意図を素早く読み取って
> プラグイン作る人さえそろえば、
> 少ない労力で結果として効果の高いソフトが作れると思うよ。

そうだな。早く藻前がそれを作って公開すればみんなそれがどれくらい素晴らしいか理解できると思うよ。
とっとと作れ。
0455デフォルトの名無しさんNGNG
>>448
また、使ってないやつがコメントしてるのか。
S2は自動バインディングがほんとだから
DIについてはクラスの登録以外はあまりすることがない。

Springの設定ファイルについて文句あるなら、
Springすれでどうぞ。
0456デフォルトの名無しさんNGNG
スレ違い+勘違いUzeeeeeeeeeeeeeeeeee!!!
0457デフォルトの名無しさんNGNG
比嘉氏のドメインモデルに対する懸念には同意だ。
ビジネスモデルも柔軟性があり、いい発想だ。
しかし、ドメイン分析をまともに出来る奴がいねーのは問題だわな。
巷にはノウハウ本が溢れているが、だーれも読んでねーってことだ。
読者がアホなのか、執筆者がアホなのか。
まぁ、後者だろう。
0458デフォルトの名無しさんNGNG
>>457
> 読者がアホなのか、執筆者がアホなのか。
> まぁ、後者だろう。

○ージス総研と○蔵に通報しますた。
0459デフォルトの名無しさんNGNG
>>458
つうか、日本でドメイン分析をまともにやったプロジェクトはないだろ。
あるなら教えてくれ。
まぁ、未経験者の執筆した本でも趣味でやってる奴には楽しめるかもしれん。
0460デフォルトの名無しさんNGNG
もし仮に、diconをポトペタできる様なRADツールが存在したとして、需要が有るか否か
もし仮に、diconをポトペタできる様なRADツールを作るとして、実現可能性はどれくらい
あるか?
または既にそういったツールが有るのか否か、情報提供キボーン
0461デフォルトの名無しさんNGNG
>>460
こんな年の暮れに何をかいとんねん。
もう新年だけど。
diconをぽとぺたする意味が良く分からん。
ツールならKijimunaはけっこう良くできてるよ。
0462デフォルトの名無しさんNGNG
皆様、あけましておめでとうございます。
なにはともあれ、今年もIT屋さんとしてがんばっていこうではありませんか ;-)
0463デフォルトの名無しさんNGNG
>>455
自動バインディングのために、クラスに定数定義したり、
やっぱりxml書かなきゃいけなかったりする。

そこまでする理由ってのが、どうにも見つからないんだな。
結局、Javaプラットフォームがプログラミングしづらいから、
なんとかカバーしようとしているだけとしか思えない。
0464デフォルトの名無しさんNGNG
だからJavaでやる意義を問いたいならスレ違いだって言ってんだよ。
0465あなたの運勢は 【ぴょん吉】 ですから!!残念っっ!!NGNG
m9(^Д^) プギャー
0466デフォルトの名無しさんNGNG
>>464
いや、漏れが一番知りたいのは、
Seaser作る人使う人が
ウェブ/データベースプログラミングをJavaでやると選択した理由なんだよ。

漏れの知らない深い理由があるのではないかなと。
0467デフォルトの名無しさんNGNG
>>466
・CGIは力不足
・mod_{perl,ruby}は挙動が怪しいときに追うのが辛い
・PHPは言語仕様が糞

あとは別ヌレでどうぞ
0468デフォルトの名無しさんNGNG
>>467
モチツケ
0469デフォルトの名無しさんNGNG
>>461
実は俺>>391なんです。
Kijimunaの存在自体知りませんでしたorz

ただ、それはそれとして、設定ファイルを書くのが面倒という意見が多いんで
工夫できないものなのかな?工夫する為のツールは存在しないのかな?存
在はしてるけど認知度が低いのかな?認知されてるけど機能が足りてない
のかな?等々、現状どうなってるのか不思議に思ったものでネタ振りしたつ
もりだったんですが・・・・・・スベっちゃいました。

「手書きが面倒」という感覚は、ある種の人達(例えばLinux畑の人達とか?)
にはどう説明しても理解してもらえないんで、もしかしたらSeasar使いの人達
もその類の人達なのかと思ったんですが・・・・・・

実際のとこ、どうなんでしょう?
0470469NGNG
間違えた、>>391ではなく>>398です。

>>391さんは無関係です。申し訳ない、ごめんなさい。
0471デフォルトの名無しさんNGNG
>>466
積極的に選ぶ奴もいれば仕事上仕方なしに使う奴もいるさ。
理由はそれぞれ。Javaを使うと決まったときに少しでも楽するために
S2を使うだけだ。気にしないでキミは自分の道を行くのが良かろう。
0472デフォルトの名無しさんNGNG
>>469
手書きが面倒だからといってVBみたいになれば楽かというとそうでもなかろう。
少なくともKijimuna使ってる分にはそんなに苦労はしてない。
0473.net厨のお年玉は 【1519円】 でしたNGNG
( ´д)ヒソ(´д`)ヒソ(д` )
0474469NGNG
>>472
「そんなに苦労はしてない」この言葉にはとても多くの意味があって・・・・・・

例えば、Linuxのlilo.confは手書きです。これは設定ファイル自体が非常に
単純で、GUIエディタを作るまでもないというのがLinux畑な人達の言い分な
んだと思うんですが、一方でグラフィカルなブートマネージャに対する人気
は凄く高いという側面もあります。

決して批判してるわけではないんですが(批判できるほどSeasarを理解でき
てませんorz)、使いこなしてる人ほど見えなくなる部分みたいなんで一石を
・・・・・・MSはそういうとこ上手いと思う。

て言うか、俺自身が更にSeasarやEclipseを学んで、ポトペタdiconプラグイン
for Eclipseとかを作れる様になればいいんですけどね・・・・・・遠いなぁ(´д`;)
0475デフォルトの名無しさんNGNG
>>467

> mod_{perl,ruby}は挙動が怪しいときに追うのが辛い

これは、例えば、どういうとき?
0476デフォルトの名無しさんNGNG
>>469

私は手書き派ですが、diconファイルをクラスごとに用意してます。それでパッケージ単位でインクルードしたdiconファイルを用意していて、サブシステム単位でそれをインクルードして、さらに全てをインクルードしてます。
で、GUIでこれを出来たら楽という考えを持っています。その一方で、テスト用のdiconファイルを作っているのでそれを任意に出来るようなGUIが想像できないです。そこら辺のイメージが湧かないとGUIの評価も出来ません。
システムは多数の人間で開発するものですので、自分の変更がほかの人に迷惑をかけないようなファイル分割や、チェック方法や、排他方法を望みます。
それが可能ならGUIでもいいんですが。
0477469NGNG
>>476
ごめんなさい。書き込み内容の1/10も理解できませんorz

イメージとしては、GraphEdit(DirectShowFilterの接続をグラフィカルに
設定するMS製ツール)なんですが・・・・・・
dicon用GUIエディタをGraphEditの様なUIで表現可能なのかどうかが
先ず分かりませんorz^256
0478デフォルトの名無しさんNGNG
いや、別に単に「自分でファクトリつくるのめんどいなあ。S2でやっちゃうか」でも
十分に存在価値はあると思うんだけど。intercepter機能を一切使わなくてもね。

PHPはもうちょっとオブジェクト指向面で実績ができてからかなあ。
あと何でも連想配列でなんとかしていくのも俺は気持ち悪い。
Bean書く手間をかけても、そっちのほうがいい。それが俺のJavaを選んだ理由かな。
0479デフォルトの名無しさんNGNG
classファイルをドロップするとファイル位置を元にclassロードして、リフレクションで
完全クラス名を取得して自動的にdiconひな形作成して、GUIでプロパティ設定とか、
コンストラクタ設定とか、インターセプターとか設定できるようにすると面白そうだと
思う。

実現可能性(誰が作るのかとか)をとっぱらって考えると、こういうツールは敷居を
下げてくれるし、重要な要素だと思うよ。手書きで間に合ってる人はいらんだろうけ
ど、手書きXMLに敷居を感じる人間もいるわな。すそ野を広めようと思えば考慮す
る価値はあるよね。

俺はdicon手書きでもkijimunaでそれほど困ってないけど、正直GUIツールがあったら
便利だと思うね。チームの連中にdiconの概念を説明する手間が若干省けるし。
0480469NGNG
>>478
寧ろintercepter機能(S2AOPの事ですよね?)が使いたくてSeasarを追
っかけてます。まぁ、逃げられっぱなしなわけですがorz

例えば、今は単純なベタテキストのログを出力してるけど、将来的には
XMLで出力したい、いやいっそSYSLOGdへ出力したい、まてまてHTML
で出力してWEBブラウザで見るのも捨て難いぞ等と考えた時、それ用
のクラスを書いてdiconを編集するだけで、色んなログの出力が実現で
きるのだとしたら、とても便利そうだぞと、思ったんですが・・・・・・・

もっとも、この発想自体が間違ってる可能性も大アリなんですが(´д`;)
0481デフォルトの名無しさんNGNG
漏れはGUIよりも、XDocletで吐き出せる方が嬉しいな。
読み込み順とかも重要だから難しいかなぁ。
0482デフォルトの名無しさんNGNG
>>480
その発想は間違ってないけど、すでにApacheのLog4Jで実現されてるので
そっち使った方が早い。Log4JはSeasar自身も使ってるし。
0483デフォルトの名無しさんNGNG
あ、いうまでもなく、ログ出力の多様化の話ね。
0484デフォルトの名無しさんNGNG
ttp://d.hatena.ne.jp/higayasuo/20050102#1104650907
>Seasar3はJ2EE Development with EJBなのです。

( ´_ゝ`)フーン

Seasarいらねじゃないの?
結局EJB最強ってことか
0485デフォルトの名無しさんNGNG
今S2で作ってるシステムはS3が出たらどうすればいいんだ。すごく不安になってきたよ。
0486デフォルトの名無しさんNGNG
>>485
漏れはアンチSeaserだが、
バージョン間の互換性問題はどこの世界にもある話。
PHPは本当に酷かった。
0487デフォルトの名無しさんNGNG
>>485
だから、リファクタリングの原則だ。
これができてればバージョン上げるくらい楽勝だ。
0488デフォルトの名無しさんNGNG
なんか新年早々えらいこと言い出しましたね。
バージョン間の互換性というより、根本的に考え方が違う。
-Seasar3がでたらSeasar2どうなる。メンテナンスするの?
-今開発中のS2*シリーズは影響受けないのか?
あたりが気になる。

ttp://d.hatena.ne.jp/higayasuo/20050102#1104650907
のコメントを見ると、取り巻き達もこの件は知らなかったの?
S2マンセーな方々がどういう反応するかな?
0489デフォルトの名無しさんNGNG
Seasarの中の人も大変だな
0490デフォルトの名無しさんNGNG
>>487
売りであるS2Daoが全然変わっちゃいそうだから
リファクタリングというより作り直しになっちゃいう。
0491デフォルトの名無しさんNGNG
ttp://d.hatena.ne.jp/higayasuo/20050103#1104716008
>Seasar3は、Seasar2とは全くコンセプトが異なるので、基本的に互換性はありません。
>でも、Seasar2を使われている方は、心配する必要はありません。
>Seasar2は、今後も開発を続けます。J2SE5にも対応します。
>今後も主力は、Seasar2 + S2ファミリーということになります。

あ〜やっぱり。そうなるとS2/S3の2系列になる。それも悩ましい。
0492デフォルトの名無しさんNGNG
ひがたんは、ビジネスモデルとドメインモデルの違いを理解していない模様.
0493デフォルトの名無しさんNGNG
>>492
ドメインモデルもビジネスモデルもちゃんとした定義なんてないと思うよ。
もしかして、DDDの定義がちゃんとした定義だと思ってるとか。
0494デフォルトの名無しさんNGNG
ビジネスモデルはビジネスが成り立つことを表すためのモデル
ドメインモデルもシステム化対象となる問題領域を捉えるためのモデル
という理解ではだめか?
0495デフォルトの名無しさんNGNG
>>494
それは、それで違和感ないけど、みんないってること違うからね。
いまのところしょうがないんじゃないかな。
ファウラーたんがきちんと定義してくれたらそれがデファクトになるかもね。
ただドメインモデルの定義も
http://martinfowler.com/eaaCatalog/domainModel.html
でいいのかなぁって気も。
0496デフォルトの名無しさんNGNG
>>491
つまりSeasar3が作られたとしても、使うメリットは少ないってことだな。
Seasarという名のもとに違うコンセプトのものが語られて、開発リソースの分散と混乱をまねくだけまねいてあぼん、か。
先が見えたな。
0497デフォルトの名無しさんNGNG
>>496
藻前は、Seasar2もつかってないんだろうから、Seasar3も使わなくて良いよ。
ちなみに、Seasar2がでたときも、Seasar1と全く違うコンセプトのものだったよ。
0498デフォルトの名無しさんNGNG
ビジネスモデルをおもいっきし間違えてる。
ひがさんの言ってるビジネスモデルは「業務フロー」(ビジネスフローとでも言えばいいか)。
業務フローのなかで特有のモデルがドメインモデル。
常識的な範囲で、ビジネスモデルは儲ける方法のことだし。

煽り抜きで、ちょとがっかりした。
0499デフォルトの名無しさんNGNG
>>497
そのときは、Seasar1を捨ててSeasar2に移行したわけだろ。
まるっきりコンセプトを変えた新版を出して、旧版はそのまま継続って、そしたら新版使う理由なんかないよ。
開発リソースも限られてるわけだし、どっちかに偏らざるを得ない。
S2に偏るならS3は縮小していくし、S3に偏るなら移行のタイミングを与えられないままS2の利用者も減っていく。
違うコンセプトで同じ名前の2つのプロダクトを、混乱しないようにプロモーションする力があるようにも思えないし。
0500デフォルトの名無しさんNGNG
>>498

>ビジネスモデルとは、実際におこなっている業務、あるいは
>これからおこなおうとしている業務の形態・仕組みを指すこととします

といっているから、別に業務フローじゃないんじゃないの。
http://d.hatena.ne.jp/habuakihiro/20050103#1104733873
でいってる前者ってやつかな。
それによるとやはりちゃんとした定義はないということだけど。

それにしても、自分の考えと少しでも違うとまちがってると
いうやつが多いね。
2chだからそんなものだが。
■ このスレッドは過去ログ倉庫に格納されています