国産DIコンテナSeasarとくーす その３
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
NGNGってどうよ？みんなもう使ってるの？
使用経験とか、実戦配備情報とか、つかえねーよボケ、とかいろいろ書いてね。
あと、開発プロセス「くーす」の話題もこちらでどうぞ。
本家 seasar.org
http://www.seasar.org/
Seasar Projectグループ
http://seasarproject.g.hatena.ne.jp/
ひがやすをのここだけの話
http://d.hatena.ne.jp/higayasuo/
前スレ
その１ http://pc5.2ch.net/test/read.cgi/tech/1092044210/
その２ http://pc5.2ch.net/test/read.cgi/tech/1098885253/
関連スレ(なのか?)
Java Spring Frameworkを語るスレ
http://pc5.2ch.net/test/read.cgi/tech/1077465099/
0391デフォルトの名無しさん
NGNGmethod.getReturnType().isAssignableFrom(List.class)
↓
List.class.isAssignableFrom(method.getReturnType())
じゃないか？
0392デフォルトの名無しさん
NGNG比嘉氏が言いたいのは、ERDは早々に確定するから属性公開しても影響ないってことだろ。
039344
NGNG>もともと永続化されるデータ、テーブルで管理されるようなデータ
>というのは、その構造は、ER図などで外部に対して公開されています。
>
>一般的に言われるようなカプセル化の話は当てはまりません。
外部の意味が曖昧なので推測で。
ここでい言う「外部」が
>>392
>比嘉氏が言いたいのは、ERDは早々に確定するから属性公開しても
>影響ないってことだろ。
ということであれば、それでもなお、カプセル化の話は当てはまると思います。カプセル化さえされていればクラスの内部で、Extract Classした先への委譲でも、Replace Type Code with State/Strategyでも、なんでもやりたい放題できますから。
また、「外部」が外部システム等であったとしても、若干の不自由は強いられるかもしれませんが、それでもなお上記の理由でカプセル化する利点は存在すると考えます。
0394デフォルトの名無しさん
NGNGこのスレ荒らしてあげて下さい。
ウイルス貼りまくっていいですよ。
歓迎します。
039544
NGNG>補足しておくと、ドメインモデルは、もともとデータを持ってる
>クラスに振る舞いを持たせたほうが良いという観点なはずです。それが、
>
>public class Employee {
> private PayCaluculator calculator;
> ...
> public BigDecimal caluculatePay() {
> return calculator.calculatePay(this);
> }
>}
>
>という形だということは、役割でクラス分割するのと実質同じです。
Extract Classは以下のように行うので
http://www.refactoring.com/catalog/extractClass.html
PayCaluculatorクラスができることはありませんです。
0396デフォルトの名無しさん
NGNG> すまん、膨大な繰り返し処理って具体的にはどんな業務ロジックなんだ？
> 想像できんので教えてくれ。
業務ロジックかどうかは微妙だけど java.awt.Point数万個を使うようなグラフィック処理。
あと、石油埋蔵量予測システム。(どっかで読んだ)
0397デフォルトの名無しさん
NGNGサンキュ。そういうやつか。俺の仕事では出会うことは無さそうでほっとした。
0398デフォルトの名無しさん
NGNGMAIN─Seasar─dicon
│
├クラスＡ
├クラスＢ
├クラスＣ
└クラスＤ
「SeasarとはクラスＡ−Ｄの纏め役で、どれを使うかdiconに
書いておけば、そのクラスを返してくれるもの。」
という理解で合ってる？ドキュメントを１ヶ月ほど読み耽って
やっとこ辿り着いた答えがコレだったんだけど・・・・・・
0399デフォルトの名無しさん
NGNG0400デフォルトの名無しさん
NGNGひがさんが問題としていることは、OOSEでも取り上げられているから。
0401デフォルトの名無しさん
NGNG0402デフォルトの名無しさん
NGNG0403デフォルトの名無しさん
NGNG>その原因は、過度なデータ中心のクラス設計にあると私は考えています。
>データと振る舞いを1つのクラスにまとめるのは、自然なことですが、
>あるデータを使う機能をすべて1つにまとめると役割持ちすぎなクラスに
>なりやすいと考えています。
OOSEのP120~P129はその答えとなりませんか?
0404デフォルトの名無しさん
NGNGちょっとコードを書けばすぐにわかると思うんだけどね。
最近はドキュメント読んだだけで済ませようとする人が
多いのでびっくりだ。
0405デフォルトの名無しさん
NGNG>データと振る舞いを1つのクラスにまとめるのは、自然なことですが、
>あるデータを使う機能をすべて1つにまとめると役割持ちすぎなクラスに
>なりやすいと考えています。業務アプリケーションなどはとくそうで、
>直接関係のない機能が1つのエンティティに押し込まれやすくなります。
そうなった場合に適宜リファクタリングしてやれば解決する問題だと考えます。
>また、複数のデータにまたがるような機能は、そもそも適したクラスに
>振る舞いを割り当てるのが難しくなります。
複数のデータにまたがるような機能が全てそうだとは言いませんが、どのドメインオブジェクトへも割り当てがたい責務はコントローラクラスへ割り当てれば良い、と古のOOSEに記されています。そのことには異存ありません。
# UnifiedProcessは全く追っていないので、もうobsoleteなのかもしれませんが
データと振る舞いをひとつのクラスにまとめる。責務が多くなりすぎたらクラスを分割してやる。振る舞いを割り当てるのに適したクラスが無い場合はコントローラクラスとする。これでも駄目なのでしょうか?
0406デフォルトの名無しさん
NGNG読む人のせいにする筆者
0407401
NGNG最新版のドキュメントは、昔と較べると段違いに充実していると思う。
# S2JSFのドキュメントがないのは、正式公開前だし、しかたないだろう。
まさたかさんの入門記事も参考になる。
http://d.hatena.ne.jp/masataka_k/searchdiary?of=15&word=%2a%5bseasar%2dtutorial%5d
（もしかすると若干記述が古くてハマるかもしれん）。
俺はS2財団の人ではない。単なるファンだ。
だが、煽りが出たらごめん。> やすを氏ほか。
あと技術的な話をしているところを、側面的なネタで汚してすまん。
0408デフォルトの名無しさん
NGNGそうですか・・・・・・やっと、やっとここまで辿り着きました(;´д⊂ヽﾋｯｸﾋｯｸ
>>404
ぶっちゃけその通りです＞ドキュメント読んだだけで済ませようと
「Seasar = フレームワーク」と勘違いして、「クラスを切り替えられるのは分かったから、それ
で最終的にはどうなるんだ？」という明後日な視点でドキュメントを読み続けてました。
髭剃りを他の何かだと頑なに信じ込んでしまってる人が、説明書を見ながら「髭が剃れるのは
分かったから、最終的にどうなるんだ？」と途方に暮れてる姿を想像してもらえれば近いので
はないかと・・・・・・
勿論、結論は「だから髭が剃れるんだよ」というものなんですが、見てる方向が違うと辿り着け
ないんですね、これが＿|￣|○|||
最後に、とりあえず現在のところドキュメントに不満はありません。
目は何も見てはいない、見ているのは脳。という言葉をちょっぴり実感した年末でしたｗ
0409デフォルトの名無しさん
NGNG>複数のデータにまたがるような機能が全てそうだとは言いませんが、
>どのドメインオブジェクトへも割り当てがたい責務はコントローラクラスへ
>割り当てれば良い、と古のOOSEに記されています。
>そのことには異存ありません。
> # UnifiedProcessは全く追っていないので、もうobsoleteなのかもしれませんが
余談ですが、昨今の、ロバストネス分析で導出されたコントロールクラスは設計モデルでそのままストレートにクラス化すべし、という風潮はあまり好きになれないです。
某オブジェクト指向本も読んでみたんですが、ドメインモデル貧血症推奨な感じで、なんだか。
RUPの人もICONIXの人も、分析段階でのコントローラクラスの責務はバウンダリかエンティティに割り当てる、もしくはコントローラ自体をクラス化する、と言ってるように思うんだが。
というか、スリーアミーゴはICONIXの人よりもきつい言い方をしてて
「コントロールクラスを実現するのに別々の設計クラスを用意するのは
適切ではない場合がある。むしろ、関連するバウンダリやエンティティを
実現する設計クラスと同じものでコントロールクラスを実現したほうが良い」
と言ってるのだが。
0410デフォルトの名無しさん
NGNGS2Daoもここのところリリースが多かったですが、追加したあのテーションとかも
ちゃんとドキュメントに反映されてるし。
0411デフォルトの名無しさん
NGNG>「コントロールクラスを実現するのに別々の設計クラスを用意するのは
> 適切ではない場合がある。むしろ、関連するバウンダリやエンティティを
> 実現する設計クラスと同じものでコントロールクラスを実現したほうが良い」
原文を知らないので良くわからないのだけど、それってStrutsで言えば、
Action内で直接エンティティにアクセスするってことかな？
0412デフォルトの名無しさん
NGNG0413デフォルトの名無しさん
NGNG0414デフォルトの名無しさん
NGNG0415デフォルトの名無しさん
NGNG> blogに、これまでのオブジェクト指向の批判を書くのは、
> 私にとってはものすごくリスクの高いことです。なにを
> 言われてもおかしくないですから。現にいろいろ言われ
> ているわけですが、それでもあえて書いているのは、こ
> れまでのオブジェクト指向がなぜうまくいっていないの
> かを考え直すきっかけになればと思っているからなのです。
「これまでのオブジェクト指向」の定義と
「うまくいっていない」とする根拠を明確に示さないとただの
戯言．今までにない自分が始めて見つけた設計方法と認識して
いるならば非常に痛い．自らの失敗経験や知りえる範囲での失
敗を踏まえた程度ではないのか．
0416デフォルトの名無しさん
NGNGOO厨ｷﾀｰ！
0417デフォルトの名無しさん
NGNG同じコトをファウラーﾀｿにも突っ込んでやってくれ。
http://www.nri-aitd.com/tips/image/g-patern_4.gif
は根拠が薄弱すぎるとひが氏なんかよりも罪深いぞ。
特に線の交差するところは重要じゃないか？
SQLのあまりにもな例といい結構ファウラーﾀｿも危ういと感じる。
0418デフォルトの名無しさん
NGNGいいんだけど、ファイル名が怪しい
0419デフォルトの名無しさん
NGNGムリだってことがハッキリしたと思う。
これ以上ソフトウェア開発を効率化しようとするなら、
例えば業務会計ソフトなら、会計ソフトをプラグインで柔軟に変更可能にするとか、
そのAPIをソースコードごと公開するとか、
そういう、実装が伴ったものになると思う。
EJBのようなアプリケーション固有の実装を伴わないフレームワークは必要無い。
0420デフォルトの名無しさん
NGNG0421デフォルトの名無しさん
NGNGわからん
前提があるからどうなんだ？
0422デフォルトの名無しさん
NGNGDI + II まだー？
0423デフォルトの名無しさん
NGNGフレームワークやパターンや開発手法を共有するしかない、ということ
0424デフォルトの名無しさん
NGNGPhotoshopやEclipseはどうなんだ？
プラグイン毎にソフト作り直すのが現実的なのだろうか
業務ソフトだってその考え方をもっと進めなきゃいかんと俺は思う
0425デフォルトの名無しさん
NGNG未だ存在しないから、せめてムダなフレームワークを使わず
ただシンプルに作り抜くことが、今できることなんだろうと思うけどね。
0426デフォルトの名無しさん
NGNG原文読め
自分がネタにマジレスってことに気付くから
0427デフォルトの名無しさん
NGNGベースを作ればあとは付加機能でしかないという分野以外で、同じようにプラグインの仕組みを考えるのはナンセンスだと思うが。
やっても意味がないという結論がでるようなことがらについて考えを進めても意味がなさげ。
0428デフォルトの名無しさん
NGNG> 手を変え、品を変え、オブジェクト指向は説明されてきましたが、情況はそれほど好転しているように思えません。
続く文章も、手を変え品を変えたオブジェクト指向の説明に見えるので、状況がそれほど好転しない気がする。
0429デフォルトの名無しさん
NGNG確かに、同じようなプラグインの仕組みは、やるだけムダなのかもしれないし
けど、うまく設計すれば、うまくいくかもしれない。
設計は難しいものになるだろうけど、チャレンジしてほしいけどね。誰かに。
S2やEJBは何の解決にもならないのは確か。
ならシンプルな技術基盤で作りたいね。
Javaを使ったウェブプログラミングがめんどくさいからいろんなフレームワーク
がでているわけで、なら別のプラットフォームを選ぶのがいいと漏れは結論した。
結果を出せるのはスクリプト言語だなと思ってる。
0430デフォルトの名無しさん
NGNG>設計は難しいものになるだろうけど、チャレンジしてほしいけどね。誰かに。
なんだよ、他人事かよ・・
0431デフォルトの名無しさん
NGNG何か新しい業務が埋め込まれたら、既存の業務に必ず変化があるし。
Plugableにするために工程とかプログラムの部分部分がちょっとでも複雑になるなら、普通にシンプルに作って、わかりやすく変更できるようにした方がよさげ。
0432デフォルトの名無しさん
NGNGプラグイン機構を持ったソフトを売るか、それ自体を使ったソリューションビジネスを始めようってんでも
ない限り、そういう先を読んだ拡張性を重視するのは、危険だな。
You aren't gonna need itの原則だ。
まさに、普通にシンプルがよさげ。
まぁ、プラグイン機構を持つのに向いている分野もあれば、向いてない分野もあると思う。
向いている分野も結構あると思うんだけどね。
0433デフォルトの名無しさん
NGNG0434デフォルトの名無しさん
NGNG皆さんネタ厨に餌を与えないでください。
0435デフォルトの名無しさん
NGNG多分、無知だからだと思うんだ。
だから、スクリプト言語によるウェブシステム構築よりSeaserで作ったほうがイイ点、
勝ってる点を教えてください。
0436デフォルトの名無しさん
NGNG規模とか開発の人数によるよ。
スクリプト言語よりもJava+Seasarの方が、均質なコードを書くための労力が少ない。
均質なコードを書く労力が問題なければ、スクリプト言語でいいと思う。
0437デフォルトの名無しさん
NGNG0438デフォルトの名無しさん
NGNG0439デフォルトの名無しさん
NGNG感じだったような。今はどうであれ、先の事はわからない。
0440デフォルトの名無しさん
NGNG0441デフォルトの名無しさん
NGNG>440
だから、それはなぜかを示してほしい
0442デフォルトの名無しさん
NGNGJavaプログラマは素人。
よって、Javaプログラマには基幹系は無理。
以上。
0443デフォルトの名無しさん
NGNG二番目が根拠無し
0444デフォルトの名無しさん
NGNG別のとこでやってくれ。
0445デフォルトの名無しさん
NGNG0446デフォルトの名無しさん
NGNG均質っていうけどなぁ、
均質にするのは方法論であって。
その方法論を実現するのには、コンパイルに依存しない
弱い結合が必要だっていうから、Seaserがあるわけでしょ。
コンパイル依存をなくしたいと思って行きつくところは、
動的なスクリプト言語ってことにならないだろうか？
それに、O/Rマッピングとか、ソフトウェアを複雑にする要因を
増やしてもしょうがないと思う。
0447デフォルトの名無しさん
NGNG実装との依存性はなくしたいだけど、
仕様(interface)との関係は明確にしたい。
仕様に合致してるかどうかはコンパイラにチェックして欲しい。
O/Rマッピングは関係無いと思うけど。
S2Daoの話なら別に複雑じゃないよ。
0448デフォルトの名無しさん
NGNGしかし、キャスト要らずのコードにするために、
あのdiで書かれた設定ファイルが必要になるわけで、
どっちにしろ動かしてみるまで分からないのは一緒だと
思うのだけど、どうだろうか。
それに、あのdiファイルってすごく冗長で書くの辛いしツール要るしで、
なんか本末転倒感が強い。
0449デフォルトの名無しさん
NGNG0450デフォルトの名無しさん
NGNGプラグイン機構を持ってもしょうがない、
ってな話あるけど、必ずしも、
そうでもない気がする。
ERPソフトの全てがネタだとは思わないし、
適切なインターフェースさえ定義して
そのインターフェースAPIの意図を素早く読み取って
プラグイン作る人さえそろえば、
少ない労力で結果として効果の高いソフトが作れると思うよ。
0451デフォルトの名無しさん
NGNGS2は特にそうだ。
0452446,448,449,450 ◆iKwMOjCT4s
NGNG言語本来備わっている名前空間機能ではいかんのか？
と思うわけだな
0453デフォルトの名無しさん
NGNG0454デフォルトの名無しさん
NGNG> 適切なインターフェースさえ定義して
> そのインターフェースAPIの意図を素早く読み取って
> プラグイン作る人さえそろえば、
> 少ない労力で結果として効果の高いソフトが作れると思うよ。
そうだな。早く藻前がそれを作って公開すればみんなそれがどれくらい素晴らしいか理解できると思うよ。
とっとと作れ。
0455デフォルトの名無しさん
NGNGまた、使ってないやつがコメントしてるのか。
S2は自動バインディングがほんとだから
DIについてはクラスの登録以外はあまりすることがない。
Springの設定ファイルについて文句あるなら、
Springすれでどうぞ。
0456デフォルトの名無しさん
NGNG0457デフォルトの名無しさん
NGNGビジネスモデルも柔軟性があり、いい発想だ。
しかし、ドメイン分析をまともに出来る奴がいねーのは問題だわな。
巷にはノウハウ本が溢れているが、だーれも読んでねーってことだ。
読者がアホなのか、執筆者がアホなのか。
まぁ、後者だろう。
0458デフォルトの名無しさん
NGNG> 読者がアホなのか、執筆者がアホなのか。
> まぁ、後者だろう。
○ージス総研と○蔵に通報しますた。
0459デフォルトの名無しさん
NGNGつうか、日本でドメイン分析をまともにやったプロジェクトはないだろ。
あるなら教えてくれ。
まぁ、未経験者の執筆した本でも趣味でやってる奴には楽しめるかもしれん。
0460デフォルトの名無しさん
NGNGもし仮に、diconをポトペタできる様なRADツールを作るとして、実現可能性はどれくらい
あるか？
または既にそういったツールが有るのか否か、情報提供キボーン
0461デフォルトの名無しさん
NGNGこんな年の暮れに何をかいとんねん。
もう新年だけど。
diconをぽとぺたする意味が良く分からん。
ツールならKijimunaはけっこう良くできてるよ。
0462デフォルトの名無しさん
NGNGなにはともあれ、今年もIT屋さんとしてがんばっていこうではありませんか ;-)
0463デフォルトの名無しさん
NGNG自動バインディングのために、クラスに定数定義したり、
やっぱりxml書かなきゃいけなかったりする。
そこまでする理由ってのが、どうにも見つからないんだな。
結局、Javaプラットフォームがプログラミングしづらいから、
なんとかカバーしようとしているだけとしか思えない。
0464デフォルトの名無しさん
NGNG0465あなたの運勢は 【ぴょん吉】 ですから!!残念っっ!!
NGNG0466デフォルトの名無しさん
NGNGいや、漏れが一番知りたいのは、
Seaser作る人使う人が
ウェブ／データベースプログラミングをJavaでやると選択した理由なんだよ。
漏れの知らない深い理由があるのではないかなと。
0467デフォルトの名無しさん
NGNG・CGIは力不足
・mod_{perl,ruby}は挙動が怪しいときに追うのが辛い
・PHPは言語仕様が糞
あとは別ﾇﾚでどうぞ
0468デフォルトの名無しさん
NGNGモチツケ
0469デフォルトの名無しさん
NGNG実は俺>>391なんです。
Kijimunaの存在自体知りませんでしたorz
ただ、それはそれとして、設定ファイルを書くのが面倒という意見が多いんで
工夫できないものなのかな？工夫する為のツールは存在しないのかな？存
在はしてるけど認知度が低いのかな？認知されてるけど機能が足りてない
のかな？等々、現状どうなってるのか不思議に思ったものでネタ振りしたつ
もりだったんですが・・・・・・スベっちゃいました。
「手書きが面倒」という感覚は、ある種の人達(例えばLinux畑の人達とか？)
にはどう説明しても理解してもらえないんで、もしかしたらSeasar使いの人達
もその類の人達なのかと思ったんですが・・・・・・
実際のとこ、どうなんでしょう？
0471デフォルトの名無しさん
NGNG積極的に選ぶ奴もいれば仕事上仕方なしに使う奴もいるさ。
理由はそれぞれ。Javaを使うと決まったときに少しでも楽するために
S2を使うだけだ。気にしないでキミは自分の道を行くのが良かろう。
0472デフォルトの名無しさん
NGNG手書きが面倒だからといってVBみたいになれば楽かというとそうでもなかろう。
少なくともKijimuna使ってる分にはそんなに苦労はしてない。
0473.net厨のお年玉は 【1519円】 でした
NGNG0474469
NGNG「そんなに苦労はしてない」この言葉にはとても多くの意味があって・・・・・・
例えば、Linuxのlilo.confは手書きです。これは設定ファイル自体が非常に
単純で、GUIエディタを作るまでもないというのがLinux畑な人達の言い分な
んだと思うんですが、一方でグラフィカルなブートマネージャに対する人気
は凄く高いという側面もあります。
決して批判してるわけではないんですが(批判できるほどSeasarを理解でき
てませんorz)、使いこなしてる人ほど見えなくなる部分みたいなんで一石を
・・・・・・MSはそういうとこ上手いと思う。
て言うか、俺自身が更にSeasarやEclipseを学んで、ポトペタdiconプラグイン
for Eclipseとかを作れる様になればいいんですけどね・・・・・・遠いなぁ（´д｀；）
0475デフォルトの名無しさん
NGNG> mod_{perl,ruby}は挙動が怪しいときに追うのが辛い
これは、例えば、どういうとき？
0476デフォルトの名無しさん
NGNG私は手書き派ですが、diconファイルをクラスごとに用意してます。それでパッケージ単位でインクルードしたdiconファイルを用意していて、サブシステム単位でそれをインクルードして、さらに全てをインクルードしてます。
で、GUIでこれを出来たら楽という考えを持っています。その一方で、テスト用のdiconファイルを作っているのでそれを任意に出来るようなGUIが想像できないです。そこら辺のイメージが湧かないとGUIの評価も出来ません。
システムは多数の人間で開発するものですので、自分の変更がほかの人に迷惑をかけないようなファイル分割や、チェック方法や、排他方法を望みます。
それが可能ならGUIでもいいんですが。
0477469
NGNGごめんなさい。書き込み内容の1/10も理解できませんorz
イメージとしては、GraphEdit(DirectShowFilterの接続をグラフィカルに
設定するMS製ツール)なんですが・・・・・・
dicon用GUIエディタをGraphEditの様なUIで表現可能なのかどうかが
先ず分かりませんorz^256
0478デフォルトの名無しさん
NGNG十分に存在価値はあると思うんだけど。intercepter機能を一切使わなくてもね。
PHPはもうちょっとオブジェクト指向面で実績ができてからかなあ。
あと何でも連想配列でなんとかしていくのも俺は気持ち悪い。
Bean書く手間をかけても、そっちのほうがいい。それが俺のJavaを選んだ理由かな。
0479デフォルトの名無しさん
NGNG完全クラス名を取得して自動的にdiconひな形作成して、GUIでプロパティ設定とか、
コンストラクタ設定とか、インターセプターとか設定できるようにすると面白そうだと
思う。
実現可能性（誰が作るのかとか）をとっぱらって考えると、こういうツールは敷居を
下げてくれるし、重要な要素だと思うよ。手書きで間に合ってる人はいらんだろうけ
ど、手書きXMLに敷居を感じる人間もいるわな。すそ野を広めようと思えば考慮す
る価値はあるよね。
俺はdicon手書きでもkijimunaでそれほど困ってないけど、正直GUIツールがあったら
便利だと思うね。チームの連中にdiconの概念を説明する手間が若干省けるし。
0480469
NGNG寧ろintercepter機能(S2AOPの事ですよね？)が使いたくてSeasarを追
っかけてます。まぁ、逃げられっぱなしなわけですがorz
例えば、今は単純なベタテキストのログを出力してるけど、将来的には
XMLで出力したい、いやいっそSYSLOGdへ出力したい、まてまてHTML
で出力してWEBブラウザで見るのも捨て難いぞ等と考えた時、それ用
のクラスを書いてdiconを編集するだけで、色んなログの出力が実現で
きるのだとしたら、とても便利そうだぞと、思ったんですが・・・・・・・
もっとも、この発想自体が間違ってる可能性も大アリなんですが（´д｀；）
0481デフォルトの名無しさん
NGNG読み込み順とかも重要だから難しいかなぁ。
0482デフォルトの名無しさん
NGNGその発想は間違ってないけど、すでにApacheのLog4Jで実現されてるので
そっち使った方が早い。Log4JはSeasar自身も使ってるし。
0483デフォルトの名無しさん
NGNG0484デフォルトの名無しさん
NGNG＞Seasar3はJ2EE Development with EJBなのです。
( ´_ゝ`)ﾌｰﾝ
Seasarいらねじゃないの？
結局EJB最強ってことか
0485デフォルトの名無しさん
NGNG0486デフォルトの名無しさん
NGNG漏れはアンチSeaserだが、
バージョン間の互換性問題はどこの世界にもある話。
PHPは本当に酷かった。
0487デフォルトの名無しさん
NGNGだから、リファクタリングの原則だ。
これができてればバージョン上げるくらい楽勝だ。
0488デフォルトの名無しさん
NGNGバージョン間の互換性というより、根本的に考え方が違う。
-Seasar3がでたらSeasar2どうなる。メンテナンスするの？
-今開発中のS2*シリーズは影響受けないのか？
あたりが気になる。
ttp://d.hatena.ne.jp/higayasuo/20050102#1104650907
のコメントを見ると、取り巻き達もこの件は知らなかったの？
S2マンセーな方々がどういう反応するかな？
0489デフォルトの名無しさん
NGNG0490デフォルトの名無しさん
NGNG売りであるS2Daoが全然変わっちゃいそうだから
リファクタリングというより作り直しになっちゃいう。
0491デフォルトの名無しさん
NGNG＞Seasar3は、Seasar2とは全くコンセプトが異なるので、基本的に互換性はありません。
＞でも、Seasar2を使われている方は、心配する必要はありません。
＞Seasar2は、今後も開発を続けます。J2SE5にも対応します。
＞今後も主力は、Seasar2 + S2ファミリーということになります。
あ〜やっぱり。そうなるとS2/S3の２系列になる。それも悩ましい。
■ このスレッドは過去ログ倉庫に格納されています