- 1 名前：デフォルトの名無しさん mailto:sage [2007/01/23(火) 10:59:45 ]
- 前スレ
ttp://pc10.2ch.net/test/read.cgi/tech/1077465099/
公式
ttp://www.springframework.org/
- 171 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 18:06:50 ]
- >>168 に近い感覚。
- 172 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 18:07:22 ]
-
工エェェェ（´д｀）ェェェエ工
- 173 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 19:05:52 ]
- 昨年末に買ったSpring2.0入門やっと読破したｗ
いいねこの本
- 174 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 19:09:12 ]
- >>173
だんな乙
なんて言わないですよ
だってここはSeasarスレではないのですからｗ
- 175 名前：166 [2007/02/10(土) 19:25:44 ]
- >>168
なるほどねぇ。
いやぁ、私もSpring使った開発に足つっこんじゃってて。
正直、使う前に予測してた弊害にモロにやられてるから。
ノウハウが足りないってのもあるけろ。
改めて思うのは、DI自体にそこまで価値あるのかしらっていう。
>>トレースログとか、トランザクション周りを排除できるだけでも使う価値はあるとおもう。
激しく同意だけど、これってAOP的要素なんだよね。
オブジェクトの疎結合によるメリットはまだイマイチ感じれないなぁ。
- 176 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 20:21:51 ]
- ただ導入すればメリットをえられると思っている単細胞には、ﾅﾆを使ってもメリットは得られないだろうねぇ
そういうヤツは何も考えずにゴリゴリ書いてガッツリ結合したプログラムを、またゴリゴリメンテナンスするのが
日常だから、考えてプログラム作ること自体がデメリットになっちゃうんだよね
そういう奴らが主導権を握ったプロジェクトだと、こっちまで巻き添えくうから困る
- 177 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 20:23:19 ]
- >>175
使う前に予測してた弊害って何？
- 178 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 20:38:13 ]
- 疎結合そのものにメリット感じられないなら
DI使ったプロジェクトには来ないで欲しいよ・・
- 179 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 20:39:20 ]
- って言うか、オブジェクト指向言語使った開発全般に（ｒｙ
- 180 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 20:41:44 ]
- >>175
まずは依存関係逆転の原則でググれ。
- 181 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 20:43:54 ]
- >>175
>> 激しく同意だけど、これってAOP的要素なんだよね。
そうなんだよね。AOPを使ってトランザクション制御を書かなくていいんだ！ってのは理解してもらえるんだよ。
try,catch,finally close()とかはみんな煩わしいと思ってるし。
問題はDIの部分なんだよね。
setterインジェクションでDaoとか渡さなくても自分でnewすればいいじゃんてなる。
やれInterface書くのめんどくさくないの？とかsetter書くのがめんどいだのいうわけよ。
Daoなんか1個実装すれば終わりだし、ORMが途中で変わるわけないだろとか。
うちの人間は極端にリソースが増えるのを嫌がるからなぁｗ わからなくもないんだけどね。
- 182 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 20:45:07 ]
- Interface書くのがめんどくさいとかいうヤツは
コボルでもやってりゃいいんだよ
- 183 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 20:46:26 ]
- >>181
そういう奴らの方がよっぽどめんどくさい事を一生懸命やっているっていう事実を
当人達が気が付いていないのが笑える
- 184 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 20:46:53 ]
- >>181
自分でnewして良いかどうか、
JUnitでテストケースかいてみりゃ一発でわかるだろ。
- 185 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 20:53:15 ]
- PGレベルのやつはspring意識しなくて良いから「勉強ダルい」なんてことはないと思われ。
上でもあるが、トランザクションやログなど、アプリケーションの動作をプログラムから排除することで、
オブジェクト指向設計したメソッド呼び出しのみに注力することができるので見通しが良くなる。
- 186 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 21:07:56 ]
- 蜜結合大好きならスクリプト言語の世界へどうぞ。
- 187 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 21:44:14 ]
- 宣言的トランザクションを利用する場合も
TransactionManager, DataSourceなどをBean定義ファイルで設定してるよね？
あれってDIだよね？ｗ
これはkiddingだけど、
DIの価値がよくわからなければnewすることからはじめてもいいのでは？
それで問題がなければＯＫだし、その過程でDIの良さを理解できるかもしれないし。
一気にモジュールを作成してUnit Testをせずに
結合して単体テストするという文化ではnewでいけるのかも？
- 188 名前：デフォルトの名無しさん [2007/02/10(土) 22:21:29 ]
- 飲み過ぎだろ・・・常識的に考えてｗｗｗ
- 189 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 22:22:41 ]
- 誤爆しましたｗ
- 190 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 23:37:41 ]
- あなたの常識って何ですか？東国原
- 191 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 23:53:40 ]
- ＞DIの価値がよくわからなければnewすることからはじめてもいいのでは？
＞それで問題がなければＯＫだし、その過程でDIの良さを理解できるかもしれないし。
単に、問題の存在に気づかないだけだとおもう。
- 192 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 00:07:00 ]
- かもなｗ
- 193 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 00:08:26 ]
- >>191
問題って何？
- 194 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 00:20:52 ]
- 理解力不足と、そう思われるのがイヤで
難癖付けるヤツ
- 195 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 00:22:42 ]
- 自分自身のこと？ｗ
- 196 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 00:26:03 ]
- あと、空気読めないガキ
- 197 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 00:26:37 ]
- なんか現状に不満みたいだねｗ
- 198 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 01:54:09 ]
- >>191-197
これがSpringを導入するかしないかで繰り広げられる会話か。
- 199 名前：166 [2007/02/11(日) 02:53:16 ]
- うあ。大反響だ。
この中で実際開発してる人っているんですよね。
理想論は理解できるけど、どれだけ『体現』してるのかな。
それも個人ではなくプロジェクトとしてね。
ISID内じゃ前からSeasar2不評だよ。
タ ブ ー だ け ど 。
- 200 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 03:03:48 ]
- >>199
どうでもいいけど、>>175で書いてた、使う前に予測してた弊害って何よ？ｗｗｗ
- 201 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 03:04:13 ]
- 疎結合否定した時点で、真性かネタの二択だよ俺的には。
- 202 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 03:05:27 ]
- 今時DIすらわからんJava開発者は、さっさとRubyあたりに移った方が身のためだと思う
多分Rubyもわからなくて廃業するだろうけどな
- 203 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 04:05:38 ]
- 実際、楽になったといえるような香具師はいないだろうねぇ
Strutsがそうであるように、結局使いこなせなくて大変な思いだけ
が記憶に残ってしまうんだよね
とSpring使ったことないオレがイって見る
- 204 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 04:30:32 ]
- だからさっさとスクリプト言語でも何でも、簡単な方にいけばいいのに
DI以前のクソソースしか書けないJava開発者が、現場では一番使えない
- 205 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 05:27:13 ]
- ｸﾝｸﾝ
ﾑﾑｯ！！
ｺ・・・ｺﾚﾊ！！！
- 206 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 08:49:34 ]
- >>203
とことん楽になったよ。
あとStrutsと比較したらただのアホだから、
人前では決して口にしないように。
DIは(AOPも)パラダイムなんだから。
構造化言語、オブジェクト指向、とかと同列。
進化の方向は「関心ごとを極小にして実装に集中する」で一致してる。
- 207 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 10:41:51 ]
- >>203
Javaも使いこなせてないみたいだな
- 208 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 10:44:20 ]
- >>204
人の上に立てないやつ
- 209 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 10:47:07 ]
- >>199
>ISID内じゃ前からSeasar2不評だよ。
これほんと？(ぁゃιぃ)
不評な理由はなに？
- 210 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 11:01:34 ]
- なんかさ、
ジャヴァ・スプリング・フレームワーク と
ネギ・スプリング・フィールド って
なんかにてね？
- 211 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 11:03:50 ]
- ネギ・スプリング・フィールドはおまえにそっくりだな
- 212 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 11:59:28 ]
- なんか暖冬のせいか、馬鹿がたくさん沸いてでてきてるな
- 213 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 12:00:39 ]
- >>206-207
そういう意味で比較したんじゃないからｗ
日本語も読めないようなヤツだと大して使いこなせてもいないんだろう
- 214 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 12:16:30 ]
- 必死だなｗｗｗ
- 215 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 12:43:38 ]
- ネタだと思いたい。
- 216 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 12:44:51 ]
- >>212
そりゃ、春のフレームワークだからなｗ。 Spring = 春
- 217 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 12:53:49 ]
- バネもってこい！
- 218 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 12:59:28 ]
- 温泉のフレームワークじゃないの？
- 219 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 13:28:49 ]
- スプリングフィールドとかって名前の外人さんいそうじゃねｗｗｗ
- 220 名前：デフォルトの名無しさん [2007/02/11(日) 13:34:40 ]
- DIの考え方は肯定するがDIの存在は否定するよ。
DI使いこなせるやつは密結合でもちゃっちゃと作れる。
DI理解できないやつは密結合の方が早かったりする。
現実問題として多数の人間が後者なんだよ。
この状況でDIコンテナ導入するのは最適かね。
私が言っていた弊害てそういうこと。
ムキになって噛みついてきてる方々は、普段からあまりDIの良さをわかってもらえず、もどかしい思いをしているのかな。
残念ながら多くのプログラマは君達よりずっと馬鹿。
有識者やセンスある人の内輪で盛り上がり、気付いたらJavaの市場規模は縮小してました なんて平気でおきそうで。
『誰にでも』簡単に、より速く これが理想でしょ。
まあ上位開発者がフレームワークでDIを完全に隠蔽できればどーにかなるんらけろ
- 221 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 13:42:17 ]
- >>220
作業の分担の仕方を変えれば、あっさりうまくいくよ。
旧来式：
・うまい奴が難しい業務
・下手な奴が簡単な業務
DI導入後：
・うまい奴が全業務のインタフェースを切る
・下手な奴はインタフェースを実装する
- 222 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 13:55:20 ]
- >>221
そのうまい奴がいないでDI導入するプロジェクトが存在する訳だが・・・
- 223 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 13:58:16 ]
- >>222
それは流石に無謀だろｗ
- 224 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 14:08:48 ]
- うまい奴がいないプロジェクトはDI導入しようがしまいがこけるでしょｗ
- 225 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 14:10:14 ]
- 自分はわかっていると思っているヤツがいるプロジェクトが一番危ういｗ
- 226 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 14:11:41 ]
- DIxAOPの宣言的トランザクションや他フレームワークとの連携機能は使いたいが、
DIのメリットが享受できない、理解できない場合は蜜結合すりゃいいんだよ。
- 227 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 14:12:16 ]
- 220は導入主導したやつにうまい奴だと期待されたんだな。
お前は何も悪くない。そいつの目が節穴だっただけだ。
＞上位開発者がフレームワークでDIを完全に隠蔽できればどーにかなるんらけろ
こんなのは当たり前にやってることなんだよ、普通なら。
- 228 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 14:15:42 ]
- >>225
他の奴がわからないと、調べろよとか、
そんな馬鹿な奴らと仕事したくないとか、
俺が５人いたらなとか言う奴がアーキテクチャーを
仕切っていると確かにやばいなｗ
そういう奴は自己中でプロジェクトの成功だとかコストといった観点が抜けてる。
- 229 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 14:21:33 ]
- >>222だが、
DI導入を推進してすんごいインターフェースきりまくった奴が逃げ出した
残骸見る限り使い方もわかってない様子。
- 230 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 14:22:15 ]
- >>228
＞他の奴がわからないと、調べろよとか、
＞そんな馬鹿な奴らと仕事したくないとか、
むしろDIコンテナは、雑魚に何らの調査力を期待しないで済むように
デザインされていると感じるが。
- 231 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 14:24:00 ]
- >>229
何がいいたいかわかんね
- 232 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 14:24:47 ]
- DIコンテナといったコンテキストの話じゃない
- 233 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 14:27:27 ]
- >>229
それはDIうんぬんの問題というよりも
そいつが技術的に仕切れる奴じゃなかったという話では？
- 234 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 14:33:18 ]
- そういう話
- 235 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 14:47:11 ]
- よし、今からDIとやらをやるぞ。
ところでJavaもプログラム言語も
ほぼ素人の新人なのだが、
勉強すべき用語をリストアップしてくれ！
- 236 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 14:51:10 ]
- >>235
1. 単一責任の原則（SRP：Single Responsibility Principle） クラスを変更する理由は1つ以上存在してはならない
2. オープン・クローズドの原則（OCP：Open-Closed Principle） ソフトウェアの構成要素（クラス、モジュール、関数など）は拡張に対して開いていなければならず（オープン：Open）、修正に対しては閉じていなければならない（クローズド：Closed）
3. リスコフの置換原則（LSP：Liskov Substituion Principle） 派生型はその基本型と置換可能でなければならない
4. 依存関係逆転の原則（DIP：Dependency Inversion Principle） a. 上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュールも「抽象」に依存すべきであるb. 「抽象」は実装の詳細に依存してはならない。実装の詳細が「抽象」に依存すべきである
5. インターフェイス分離の原則（ISP：Interface Segregation Principle） クライアントに、クライアントが利用しないメソッドへの依存を強制してはならない
- 237 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 14:53:55 ]
- >>235
仕事ならマジ勘弁してくれ
- 238 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 14:54:07 ]
- SRP、OCP、LSP、DIP、ISP だな？
他に知っておく技術は無いか？
俺は素人だからな。当然基礎的なものから全部だ
- 239 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 14:54:46 ]
- 「人」についての理解が重要です。
- 240 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 14:55:42 ]
- >>238
それらを習得する過程で必要なものは全て手に入る。心配するな。
- 241 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 14:56:38 ]
- >>240
その必要なものをすべてリストアップしてくれ！
- 242 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 15:05:25 ]
- >必要なもの
他の業界への転職
- 243 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 15:06:15 ]
- 明らかにスレ違いだと分って聞きます。すみません。
Spring Frameworkのような仕組みで、
デスクトップアプリを作ろうと思えば
なにを使えばいいのでしょう？
最近のフレームワークは
WebアプリでHTMLやHTMLっぽいテンプレートを
使ってUIを実装する話しばかりで困ります。
- 244 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 15:08:23 ]
- Spring Frameworkのような仕組み とは？
- 245 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 15:10:04 ]
- >>243
日本語でおｋ
- 246 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 15:14:43 ]
- >>244
えぇ、ですからいわゆるウインドウで作りたいのです。
Windows Formsとか、GTKとかQTとか。
- 247 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 15:17:15 ]
- お前はSpringをなんだと思ってるんだ？
- 248 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 15:19:34 ]
- もう一度聞く
Spring Frameworkのような仕組み とは？
- 249 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 15:21:23 ]
- >>243
電子レンジのような仕組みで、
デスクトップアプリを作ろうと思えば
なにを使えばいいのでしょう？
と質問されたら貴方はどう答えますか？
- 250 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 15:25:32 ]
- Springはよく知らないが
SpringでSwingコンポーネントを構成して、部品をFrameにDIさせて実行すればいいんじゃね？
JFrameが部品だらけでごちゃごちゃになるのは
DIコンテナを使えばある程度綺麗にまとめられる気がする
NetBeansやVEが対応できなさそうだが
- 251 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 15:31:54 ]
- >>250
NetBeans使った場合コンポーネントのプロパティがDIの定義だと考えるんだ
実際のところインターフェースベースは使い物にならないし複雑にイベントが飛び交うので無理
- 252 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 15:37:46 ]
- 無理？
- 253 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 15:41:17 ]
- >>251
Component自体が継承前提だし、実装に依存した細かなプロパティを外側から変更したいしで
よく考えれば、たしかにインターフェイスベースは無理がありそうだな
DIでの開発に慣れた後にSwingのソースを読むと、ごちゃごちゃしすぎて嫌になるが
あれはRADで開発するものだと割り切るべきか
- 254 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 15:51:03 ]
- GUIコンポーネントはプロパティが動的に変わるものだから使えないな
DIってあらかじめ挙動がわかっていて成り立つもの
ただ、GUIコンポーネント単位で使うのではなく、それらを包括した単位で扱うのなら可能
その場合フレーム単位で扱うことになるだろうね
結局はコンポーネントを制御する部分が一番厄介なところなので恩恵はあまりないけど
あとでまるごと作り直したフレームと交換とか出来るようになるのはいいのかもしれない
それでも結局サービスロケータの域からはでないな
おそらくゲームのほうが適用範囲は広いかと
- 255 名前：220 [2007/02/11(日) 15:53:50 ]
- しーましぇん、ちなみに私は>>166です。
ちなみに>>227 私は開発に加担してるけどコーディングも設計もしてないお。
>>221の言うとおりの役割分担になるんだろうね。
ただ、プロジェクトによって(人員の)質のバラつきがあるからねｗ
>>222の言うような状況は発生するんだな。
上位開発者が上手に作れば>>230の言うことおりってのもわかる。
少数の優秀なプログラマと多数の雑魚でチームが構成されても、そこそこイケそう。
>>雑魚に調査力を期待しないで済む
これねえ。 この状態に持っていけるような技術者以外DIに絡むなってことか。
私には扱えないね。
デューダするかな。
- 256 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 16:07:27 ]
- >>254
以前作った奴だと getBean 呼びまくりになって
DIでもなんでもなくなっちまったですよ。
そのアプリに適した画面フレームワークを作成した方が
最終的なコストは低く抑えられるし、
変更にもむしろ強いだろうってのがその時得た感触。
画面はやっぱ面倒ですね。
何が面倒って、お客・利用者の目にモロに触れるから
要求の変更速度がやんごとないところ。
- 257 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 16:08:25 ]
- 256はあくまでも画面(ビュー)の話ね。
- 258 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 16:18:48 ]
- つまりある程度以上の複雑さのものまでしか扱えないってこと？
- 259 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 16:19:23 ]
- 日本語変だなｗ
扱える複雑さに上限があるってこと？
- 260 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 16:20:37 ]
- どのような物にも・・・(ry
- 261 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 16:22:26 ]
- つーか・・・C#が無料なのに？DI使いたければS2.netとかもあるのに？デスクトップアプリでjava？
- 262 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 16:26:00 ]
- LinuxやMacでも動かさないとならないのです
- 263 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 16:27:48 ]
- あっそ
- 264 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 16:29:43 ]
- リッチクライアントの最先端に興味がある奴は あぱれっと様のご意見を参考にしろ。
www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?mode=viewtopic&topic=9542&forum=12&start=40
- 265 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 16:33:30 ]
- >>264
吹いたｗｗｗ
- 266 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 16:34:01 ]
- >>256
お偉いさん相手にすると見た目大事なんだよな
帳票も5mこっちにずらせとかすごい多い
WEBアプリだと多少見た目や操作性が貧弱でもいいけど、
リッチなクライアントだとほんと細かい制御をさせられるから無理
JavaSEにJAX-WSとグループレイアウトが標準搭載されたことでたぶんリッチクライアントははやると見てる
鯖もEJB3はDIコンテナになったし、どのDIプロダクトを使おうがDIは必須の知識にはなるだろうね
そしてそのPOJOで作られたEJB3コンポーネントをJAX-WSですぐに公開が可能
1年前のEJB2.1までとは別次元の開発効率になったな
- 267 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 16:36:52 ]
- １年前のPOJOでの開発と比べてはどう？
- 268 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 16:36:53 ]
- Springは細かい仕様変更要求に弱いってこと？
5mだったらこまかくないか
- 269 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 16:38:35 ]
- >>261
クライアントがWindowsだけならC#でもいいかもしれんけど、Javaのクライアントはかなり作りやすいよ
C#はDelphi時代の古いものという感じが強い
当時はBCBともどもお世話になったけど
C#だって無料なのはへぼい開発環境なやつだけなのは問題
クライアントと鯖とで技術者を2つの言語を扱える人を探すより1つの言語を扱える人を探すほうが楽だしな
>>264
一般人には考えもつかないような斬新なシステム・・・
それにしてもリッチクライアントでのJavaクライアントが多いね
1年前というJAX-RPCが使いにくい時代の割には・・・
- 270 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 16:39:42 ]
- >5mだったらこまかくないか
ﾜﾛﾀｗ
- 271 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 16:41:21 ]
- >それにしてもリッチクライアントでのJavaクライアントが多いね
Javaのフォーラムですからｗｗｗ
|
 |
