日本製Java Frameworkの駄目さ加減を語り合うスレ

マジか？
だったら、ウルのフレームワークって実態が無いのか！？

株公開後、会社崩壊のﾖｶｰﾝ

だからー
まともなフレームワークはｃFrameworkだけだって。

ウルのYがさぁ、JavaWorldの記事で、
「Frameworkの定義は人によってそれぞれです。」
ってあったの知らない？
その直後にフレームワークを構築したって言ってない？
なんかあやしくねぇ？

ウルの言っているフレームワークは、開発方法論やプロセスを含めています。
Strutsはその中の一部です。

Ｗｅｂ３フレームワーク実際に使ってみた人いる？

プロセスフレームワークだったのか・・・
RUPのカスタマイズってことだろ。
しかも、最悪のStrutsを使ってると。
完全に騙された。

>>97 Web系MVCなんてちゃんちゃら笑えるｾﾞ、って立場なんですけど、
　EJB連携上の問題点を挙げてよ。
　＃現実的な妥協案としてStruts 触り始めたの最近だけどね。

　例えば、JavaSoft pet store demo あたりに片鱗が垣間見える、
　JavaBeans - EJB間相互作用の分離、について、
　Struts では不都合があるのでしょうか？

>>105-107 まぁ、発展途上分野の国内試行例って事で、
　開発方法論＝開発プロセス＋モデリング と、
　それを裏付ける フレームワーク、コンポーネントの試作/適用を、
　がんがんがんばってほしいと思う所存です。

　ちなみに、そーゆー事ちゃんとできる人の事、ウチでは人柱っつうて尊敬してますけど。

>>109
>ウチでは人柱っつうて尊敬してますけど。
ワラタ！
そういう人を崇め奉り、万が一うまくいったらその成果をいただくのが
正解でしょう。

「日本の企業は意識してません。敵はシリコンバレーです。」
らしきこといってたやんけ＞ウル
期待してたのに・・・
所詮、豆と大差ないのか・・・

すっげーーーーーーーーーショック！！！

いんにゃ、想像力がたらんぞ。
人柱が成功して帰還した日にゃー、成功者って事になってウザイし、
次から人柱をやってくれる人がいなくなるでそ？

人柱には、挑戦的なテーマや、無理難題を押し付けて、
各種の成功要因/失敗要因に関するデータをとって、
最後に失敗させて潰すのが基本だにょー。

んで、再起しちゃったら、次の人柱になってもらうと。

↑研究開発職が確立していない、DQN企業の場合のハナシね。
　へたに研究開発が確立している企業だと、自己保身＆得手勝手入りまくりで、
　あんまおもしろくない。

>>110,112

おまえら死ね

「わたしわ、氏にましぇん」

>>109
そーゆーの、中世ヨーロッパ史なら、道化師
　　　　　　三国志なら、客家の客とか(ちぃーと不適切)、
　　　　　　現在の企業なら、ブレイン〜CTO
あたりの路線なんだけどね。

まぁ、人生なにがおもろいって、
ちょっとは現実味のある、将来こうなったらいいなっつう絵を描いて、
それを四苦八苦して実現しようとする過程にこそ、喜びがあるんでわ？

おいおい！スレのテーマからズレズレじゃん！
どうせなら、フレームワーク構築がんばっている「人柱」さん
の情報とかないの？

>>117

禿げ同。
112とかたちわる過ぎ

なんでもいいが、
ウルのＹさんがニヤケたら漫画家の蛭子さんに似ていないか？

>>120
ﾜﾛﾀ
わしは、こういうオバちゃんいるなぁとおもったが・・・

でも、うわべだけでも尊敬しとけＹＯ！！！

>>121
ははー！
そうさせていただきます。
ご指導ありがとうございます。

117さんが大勢いるような会社ってどこよ。
教えてください。

漏れの考え違いかもしれんが、
cFrameWorkやWeb3フレームワークにしても、Presentation側実装と
EJBコンポーネントとのインターフェースを標準化して、再利用性
を高めることを狙ってはいるが、本当にそれだけでいいのかね。
実はEJBコンポーネント側の設計に関してはあまり示されていない
と思うのだが。

>>123 例えば旧通産系の公募案件とかでよく名前の出るあそことか、そーでわないの？

　でも、基本は個人主義。
　DQNっぽい印象の会社で、世間的に名前を知られていなくても、
　ニーズを掘り下げて、理念は高く、でも現実に足を付けて頑張ってらっしゃる
　方が大勢いる。身近の信頼できる人に紹介してもらってはどうですか？

　ちうか、理想だけの奴集まっても成り立たんし、
　理想なしの奴だけだと発展させにくい。バランスも大切。

>>124
　アーキテクチャ・ドメインと、
　業務共通ドメイン、業務固有ドメインのお話でそ。
　アーキテクチャ・ドメインは、比較的一般性が高いので、
　たしかに目立つわな。
　業務固有ドメインだと、一般提供＝競合他社への情報提供になるから、
　公開しにくいんだろーと思う。

>公募案件

M下とかそういうの？

よくわかんないですけど。
例えばビジネス・オブジェクトとか、天才プログラマとか、究極vs至高とか(そんなのないか笑)、
旧通産省機情局とか、日本のコンピュータ・サイエンス界のスターとか集めてやってる、
あれ、の事です。

>>127
それってCBOPとかの事？

>>118 人柱さんが必要になる下等会社では、
　４層とかフレームワークの必要性とか実践しても、
　「動けばいい、無駄なことするな」ちうといて、別の場面では
　「再利用による生産性向上」とか唱え出すから、
　あまり役に立つ情報は提供できない。

　こないだNTフォールト・トレラントの説明会に行って、
　物流向けシステム開発の会社が出てて、
　「ウチは物流会社のSPIN out組でして、
　　フォークリフト免許持って現場やってた人間が C# や Javaしてますから
　　理論と実践(現場＆ビジネス戦略面)おっけです」とかのたまってたが、
　そーいう所は(J2EEフレームワークとは関係ないですが)結構信頼できそう。

　物流向けシステム開発って、ORとかグラフ理論とかバリバリ必要だし、
　やんちゃな現場の人への配慮も必要だから、すんげー面白そうだと思った。
　＃漏れの会社にもあるけど。

　そういうレベルの連中が、もっとオブジェクト指向〜業種フレームワーク分野に
　侵攻してほしいと、切に願う今日この頃...

>>128
　>>127は、公募案件の説明しただけ。
　あれに応募してるとこって、玉石混合だと思うが、
　本気で頑張ってる方は、あれへの応募を勧める。
　あちらさん(主催者側)も、本当に世の役に立つことを望んでいるしね。

　CBOPはどっちか知らん.

　技術がわかって、上層部巻き込める、
　口八丁手八丁、要領良くて誠実な、マネージャに一枚噛んでもらわないと、
　公募すら難しいけどね。

↑PS.
○応募
×公募

あと、公募案件ちぃーてるのは、
ぶっちゃけ http://www.ipa.go.jp/ のこと。

で？セキュリティ事業は？

参考スレ
http://pc.2ch.net/test/read.cgi/tech/1001950590/l50

WACsに関して全然知らないので、もう少し教えて下さい。
リンクでもいいのでお願いします。

WACsに関して全然知らないので、もう少し教えて下さい。
リンクでもいいのでお願いします。

>> 135
何が知りたいの
リンクなんてないよ。製品じゃないしね

WACsがどんなものか、どうやって手に入れるか？です。
WebSphereについているのですか？
それに対する本や資料って出ていますか？
StrutsのようにMVCフレームワークなのでしょうか？
それともライブラリとテンプレートの集合体なのでしょうか？
まったくわかりません。
よろしければ是非お願いします。

>137
>133のスレは読んだ？
WACｓの評価は概して良くない．
OODじゃなし，Javaを使うけどOOPでもない．

>>137

総じて138の言うとおり。

入手方法はIBMのSIerになるか，IBMが噛んでいるプロジェクトに
入るのが普通。著作権はあくまでIBMが持つしな。
WebSphere(WAS)についてくるわけじゃない。
製品じゃないしそれにあくまで東京のIBM部隊がつくった
ものにすぎないんでしょ。
当然本や資料もない。WACsにはドキュメントはついてるけどね。
Strutsと同じくMVCtype2のフレームワーク。

こんなとこ？

WACsって自分から使おうなんて思うシロモノじゃないよ。
将来も自分とこのハードやアプリケーションサーバーから離れられないように
するための営業の仕込んだ毒みたいなもん。
アーキテクチャはcgi以下で、時代から取り残されたCOBOラーとか多い会社でも
「すぐにナウなjavaプロジェクト始められるよ〜」ってのが唯一の売り（藁
実装する側までＯＯで書かせてくれないしEJBとかJ2EEまるでできん。
設計らしい設計できないんで使うと後のツケはでかいよ。
１０００とか２０００ステートメントのクラス作りたきゃどうぞ (^^;

>>137です。ありがとうございました。
実は社内でフレームワークを使おうって事で盛り上がっていて、
その中でIBMのがいいんでは？という意見が多勢なのです。
貴重な意見を本当にありがとうございます。
感謝します。

>>140
フレームワークってそんなもんなのですか？
なんか萎えるなぁ。
他にまともな製品ないのでしょうか。

自前で作れ＞ＡＬＬ

Assam AnyWarp

>>Assam AnyWarp
あれのどこがいいって言うんだよぉ
日立ソフト内部だって、AnyWarpを嫌がって、Struts使っている
連中がいるじゃん。

http://www.atmarkit.co.jp/fjava/devs/casestudy01/01.html
にてAssamのこと載ってるけど、個別サーブレット方式、集中
サーブレット方式という言葉は初めて聞きました。
でも個別サーブレット方式って単純な設計になるけど無駄が
多く感じます。
宗教戦争はしたくありませんが、個別って本当にいいですかね？
集中で画面が増えると既存サーブレットに手を入れないといけない
って書いてあるけどそれって設計が死んでる、もしくは個別の考え
しかできてないような気がします。
AssamってOOPはできるんですか？ネーミングルールが某みたく
きつくないですか？

>>146
>AssamってOOPはできるんですか？ネーミングルールが某みたく
>きつくないですか？
AssamはドカチンＤＯＡですがなにか？

Assamってワインバーグ氏の言うところのゴーマン法則だね。
設計の古さを機能や特徴として売っているの多いんだよねぇ。
フレームワークでそういうの。

集中サーブレット方式by日立ソ○トとか入口サーブレットbyＩ○Ｍとか
J2EEパターンについていけてない独自用語な時点で終わってる。

>>147 >>148 >>149
あが。
ドカチンDOAですかぁ。泣けてきますな。
IのWの展示会でこれからはStrutsだ、っつーてたおじさまは
Hの人だった気がするのですが。
H社内でも現場の人間にはOOは難しいんだっていいながら
DOA売り込んでる対立派閥がいるんですね。

IBMが勝手に名付けた MVC TypeII (元ﾈﾀは JSP v0.96 仕様書の JSP使用形態分類)
ってのも、本家Smalltalk他の MVC フレームワークとはｶﾅｰﾘずれててキモイ。


漏れも 6年程前に検討したけど、
・HttpRequest＝Event(の前駆体)と解釈して、
・Servlet近辺にイベント・ディスパッチャー(やRequest→Event変換)を置いて、
・Model更新→View更新の Observable-Observer関係をネグって、
やると MVCもどき にはなるが、元のMVCとは似ても似つかない…。


J2EEでは、Web層(Servlet＆JavaBean)→AppServer層(EJB)間の相互通信をシンプルにするために、
リモート・イベント通知の仕組みを作り込む必要があり、上記MVCもどきの再構成が必要になる。
この辺りは、JPSコードでも実装され、J2EEパターンとしてまとめられてるけど、
まるでゴシック様式のカテドラルでも見ているかのような眩暈を感じる。


更にさかのぼれば、オブジェクト指向のノウハウは、
パターンという、内容は明確だが抽象度や形式化が不充分なカタチでまとめられて
いるから、用語のばらつきどころか、実装解釈のばらつきもヒドイもんだ。
ただ、それは「終わってる」んじゃなくて、「ばらけていて、再利用性の障害になっている」って感じ。

＃蛇足だが、イベント・ディスパッチャーやアクセス制御機構をサーブレットの外に置けば、
＃>>149で挙げられてるやり方(集中サーブレットとか入り口サーブレット)の必然性は低い(と思う)
＃もっとも漏れは、サーブレットを一個未満で済ます主義だけど(ｗ

>>147,>>150 ドカチンＤＯＡ
Javaは、ODBを見捨てて JDBC〜ORDB方面に走った時点で、
OOとDOAの融合を目指している。

マイクロソフトもオラクルもIBMも、90年代中頃には似たような選択を済ましてたハズ。
まあ、ドカチンＤＯＡ避けたいんだったら、業務アプリから足を洗ってはいかがですか？

このあたりの事情/現状は、最近でた翻訳本
　「オブジェクト指向設計法によるデータベース設計技法―UMLによるデータ・モデリング」
　http://www.amazon.co.jp/exec/obidos/ASIN/4883030954/ref=sr_aps_b_/249-8242157-2236307
　が詳しい。
＃つうか、RDBのオブジェクト指向的解釈や、業務アプリ系のパターン集の国内発売遅すぎ。
＃漏れは、数年前からその手の洋書漁ってるYO!

>>148 設計の古さを機能や特徴として売っている
現場で製品導入して使いこなせるレベルは、所詮そのあたりだから、しょうがないよね。

業務アプリ系のパターンとか、アナパタとか、メタモデル・パターンとか、
すぐに使いこなせる人は、自分でフレームワークやパターン作ったり、
特定分野向けのパッケージ作って商売しているんだと思うよ。(汎用にするの難しいし、売れないから。)

>152
すいません。自分はへたれですのであまり大層なことは
わかりませんが、JavaがOOとDOAの融合を目指している
というのはどのへんを指してらっしゃいますか？
EJBのCMPなどがんばってるのはOODBをあきらめてはい
ないと思います。

翻訳がでるのが遅いのは本当ですね。質の低い翻訳を出される
よりはましですが。私も洋書を読みますが、高いのと国内の用語
と両方覚えなくてはならないのがつらい時があります。
全部カタカナでやってくれればいいのですが。（笑

本のご紹介、ありがとうございました。
それはまだ読んでないので読んでみます。

>153
煽りでなくなぜ現場では使いこなせないと思いますか？

いえ、皆そういうんですよ。で、現場に配属された私は腹が立つんです。
あぁ、おれは見切られたんだなぁって。（笑
私は使いこなせないとは思わないんですけどね。
ただ巨大な現場では再利用とかデザインよりも各下請けさんが
勝手に画面ごとにコーディングするほうが各社さん楽なのかな
とかも思いますけど。やっぱ足洗うべきかな。（泣藁

>151さん
6年程前に既にStrutsのアクションサーブレットのようなものを
考えられてたのですか？　すごいですね。

MVCのObserver−Observableですが、Webアプリで
ObserverをどうModelに関連づけて、Servletの起動、
Model(Bean?)の変更、Observerの起動（HTMLの出力？）
とやったのでしょう？

よければもう少し詳しく教えていただけませんか？
ヒントやポインタだけでも結構です。

あと>149さんが終わっているといったのはOOやパターンでは
なく、IやHの思考停止な商売でしょう。
パターンの用語のばらつきは商売になるのでわからずとも
語る人が多くなりすぎた嫌いがあるとおもいます。

イベントディスパッチャーというのはStrutsのアクションサーブレットと
考えてよろしいですか？
サーブレット1個未満というのは０個ですか？(笑

EVS Frameworkは（・∀・）イイ！

>>154 JavaがOOとDOAの融合を目指しているというのはどのへん

Javaが、というより、J2EE〜WebService分野限定のお話かもしれませんね。
一応補足しますと、

(1)Java APIや、Java Community Processでは、
　　ObjectDBへの対応はほとんど考えられていないように見受けられます。
　　　　http://www.jcp.org/aboutJava/communityprocess/accepted.html
(2)J2EE/EJBのEntityBeanは、データ構造とそのメンテナンス・ルーチンをまとめたものであり、
　 ObjectDBや、Serialize APIが提供する「オブジェクトの永続化機能」とは、
　 目的も機能も適用範囲も異なる、と思われます。
(3)業務アプリケーション分野の優秀な開発者の多くは、
　 RDB技術やDOA的手法(データモデリング→ビジネス・ロジック付加)に慣れており、
　 彼等には DOAの経験を生かせる OO環境を提供した方が、混乱が少ない
　 という判断が、なされているように感じます。(過去のJava APIやJSRの流れを見て。)
　

>>155 煽りでなくなぜ現場では使いこなせないと思いますか？
(1)自分自身でアーキテクチャや方法論を探索するだけの技量を持った方が少ないから。
　＃構造化〜DOAﾏﾝｾｰで、OOを知識としてしか知らない方に、洗脳手法をかけずに(ﾜﾗ
　＃納得付くで OOのメリットを説いたり、OOと彼等の手法のブリッジを提供するのは、
　＃とてつもなく知力と体力が要る仕事だろうと思います。そーゆー意味で「JavaによるOO普及」は偉大！

(2)国内では、Servletの流行まで、オブジェクト指向の軽視が続いてきたから。
　＃10年前の私の夢は、フレームワークやデザインパターン、型システム等について、
　＃あたりまえのように議論できる仕事環境の実現でした。当時を思うと隔世の感がありますが…
　＃でも、私自身はこの分野で10年間足踏みを続けていたのかもしれない。

(3)もっというと、国内では、ソフトウェア開発技術が軽視されつづけているから。
　＃優秀な人材の多くは、ソフトウェアよりハードウェアやサイエンスを志向するという実態。
　＃あるいは「ソフトウェア開発は簡単であり、現場の土方解くべき問題でしかない」という誤った考えの蔓延。

＃＃Yourdonさんのような乾いたユーモアを書くには、もっと修行が必要だと反省。

>158さん、　もったいないからage
ご丁寧にありがとうございました．
JCPまでは私は追っかけていないのでわかりませんでした．
私自信が今体験しているODAが特殊なのかもしれませんが，
私の現場ではODAはOOとは融合せず否定するものです．
その意味ではEJBとODAは絶対に混ざり合わないような気が
します．彼らのやり方ではサーブレットはデータをキャッチボール
するプログラムですし，ビーンは箱です．全く持ってOO的な
使い方はなせれていません．彼らはドキュメントからしてOOを
否定し，Javaでも手続き型プログラミングは可能だと宣言し，
彼らの提供するAPIはJavaの標準ネーミングには全く沿わず
ほぼ全てがstaticで，プリミティブ型な引数の数は限りなく多く，
Javaを少しでもかじった私にはとても信じられないものです．
Sunの進める道がODAとOOの融合であると仰られる１５８さんの
意見には私のODAに対するネガティブな感情からは多少不安を
もたらしますが，今現在のSunの進め方からすれば安心してみ
ていられると感じます．
（３）についてもう少し具体的な例をご教授願えませんでしょうか？
私はCMPのSQLの隠蔽やアプリケーションサーバが簡単に
Objectとして作成できることにOOの良さを感じているのです．
なんというか，単純な通信をうまく皮をかぶせてOOっぽくしてくれ
ているような．その方向は常に一方向で，その濃度はゆっくりと
だが徐々に濃くなっていくような．

すいません。
漏れの肛門は、なんで開発すればいいでしょうか？

すみません．ODA　−＞　DOAです．
ほんとアホですね．
逝ってきます．

>>157
聞いたことないけど。
あとホムペみたけど、これって単なるJ2EEの機能じゃん。
素人会社を狙って営業するためのネタなんだね。

159さん，ありがとうございます．

（１）は本当にそうですね．残念なことですが．でもそういう人は不景気
による生き残り競争のおかげで減ってきてはいると思います．
（３）な人は（１）な人でプログラムなんて誰が書いても同じになる，
俺が設計してやってんだよって人に多い気がします．
そんな人ほど基礎体力がなってなくて，設計がとてもひどかったり
しますが．
（２）は私にはJavaそのものとAppletの出現，Webの大流行で
花開いたと感じております．CGIにはPerl大流行という私にとって
あまりうれしくない側面がありましたから．Servletが出現してから
も，Javaで記述されたServeｒに拘ったSunは最初失敗していたと
思います．まぁ，時期的には誤差の範囲ですが．(笑

私自身はなぜOOが現場に普及しないかという答に悪い意味での
仕様書主義を感じます．彼らの仕様書記述からのWaterFallへの
拘りは凄いですから．そしてステップ数での評価でしょうか．
彼らにとってはリファクタリングを施しステップ数を減らしたり
することは信じられないことのようです．
そして最後にはやはりOOへの不信です．結局各社のSpecificな
要求への対応には抽象化も再利用もないと思っているようです．

私はちっぽけなプログラマとして，ポリモルフィズムによる単純化，
それによる信頼と変化への柔軟性．カプセル化による安定．
そしてメソッドがクラスに属すことの構造の美しさ，理解のしやすさ．
それだけでもOOが使いたくてしかたありません．でも全否定されて
しまうんです．だって，それはDFDでは表せませんから．

私も頑張って私の望むやり方が多大なメリットをもたらすのだという
ことを現場で説明できるようにならなければなりませんね．
でなければただのオタクのわがままですから．
でも最近かなり鬱です．(笑
勉強します．

日本には、フレームワークっていっぱいありますが、結局、ＯＯで開発を行う
ことを前提としているものは無いようですね。
わたくしも、assam使って開発しましたが、まさしくドカチンにふさわしい
仕様書の嵐なので辟易してしまいました。
というか、あれは、ＤＯＡ以前ですね。
だって現場では、データモデルなんて一切書かずに、テーブル定義書を直接
書いているのですから。
そういう意味では、ほとんどのフレームワークって以下の�@に対応？
�@ドカチン工学不在主義対応フレームワーク
�A一応ＤＯＡまともに考慮しているフレームワーク
�BＯＯ開発をちゃんと考慮しているフレームワーク

私見ですが、オブジェクト指向での分析クラスモデル（ＢＣＥモデル）を
フレームワーク前提での設計モデルに展開させることはそんなに難しく
ないと感じています。
＃実際にはそういったことすら説明しているフレームワークってありませんが
＃どうしてなんでしょうね？？？

一番問題なのは、ＯＯによる開発方法論に無理解な人が多すぎて、フレーム
ワークに変なことを求めすぎる傾向が強すぎることでは？

>>160
丁寧なレス、どうもありがとうございます。

「OOとDOAの融合」に関する私の説明(>>158)全然説得力ないかもしれませんね(漠。
＃結局>>152の本「オブジェクト指向設計法によるデータベース設計技法―UMLによるデータ・モデリング」の存在知って「OOとDOAの融合って路線でおっけかなぁ」と言ってみるテスト(爆
　

数ヶ月前、IBM alphaWorksの [OOとDOAの(派閥)対立] に関する記事を見たときは、
我が意を得たり などと思い、記事のURLやプリント配りまくったもんです...

が、冷静に考えてみると、OOとDOAの対立を殊更強調するのも愚かに思えます。

むしろ、OOA/OODと、DOA的手法や、Yourdonの構造化手法の連続性を踏まえて、
各手法間のギャップを埋めつつ、地道にOOのメリットを実証していくのが
現実的かもしれません。

＃仕事上でOOを試行錯誤するとか、
＃OOとDOA/構造化の違いを謙虚に示すだけでも、
＃上司や周囲の理解は不可欠ですよね。
＃なんて事をしているうちに、自分の修行は足踏み状態。

>>160　>>158（３）についてもう少し具体的な例
って、難しいです。
・ことさら相違点を強調して、拒絶反応や対立を引き起こすか、
・あるいはOOとDOAの共通基盤を明らかにした上で、
　いくつかの追加と変更をするか、
って違いなので、リファレンスを示すのは難しい。。。

>>156
ドカチン・コードの問題点とか、直すべき優先順位って、どんな感じでしょうね。
・共通機能の括りだしの欠如
・再利用性の欠如
・モデリングの欠如

＞私見ですが、オブジェクト指向での分析クラスモデル（ＢＣＥモデル）
　http://www.mamezou.com/tec/Tips/umlForumJp2001/umlArchi.html
のあたりの議論ですね。
私も、パターン本買い漁ったり、高木さんや萩本さんが Horb〜JHB MLで議論された
当時から、気にはなってます。
＃つうか、この辺りの話知ってると、
＃「Servlet＆JSPで、MVC(type1)実装しますた」みたいな議論のいい加減さに噴いちゃったりします。

結局、J2EE/MultiTear向きのアーキテクチャ・パターンは、MVCか改良MVCかPACかPADかBrokerのうちどれか1つ
なんて事はなくて、
アプリやフレームワークの実装段階では、細かい検討や投げやりな決断積み重ねて、
その結果を他に説明する段階で「MVC typeII」とか「Brokerパターン」とかお話作ってた方が、
健全な感じがします。。。

＃Struts とか Barracudaとか J2EE BluePrintが、MVCを出発点に修正図ってるのもスゴク理解できるけど。

160です
>>168
>http://www.mamezou.com/tec/Tips/umlForumJp2001/umlArchi.html
>のあたりの議論ですね。
ちなみに、萩本さんはＭＶＣ、ＰＡＣとＢＣＥモデルを同じような次元で
説明されていますけど、これって誤解を招きそう。
このスレの皆さんはレベル高いからわかっていらっしゃると思いますが
ＢＣＥはあくまでもＯＯＡにおける抽象モデルであって、
ＭＶＣ、ＰＡＣのようなアーキテクチャとは視点が違うんじゃないでしょか。
つまり、ＢＣＥでの分析モデルは、設計以降で適用されるアーキテクチャに
対してニュートラルであって、特定のアーキテクチャを示すものではない
と思うんですが、どーでしょう？

>160です
すみません。
165の間違いでした。

>>http://www.mamezou.com/tec/Tips/umlForumJp2001/umlArchi.html
>>のあたりの議論ですね。
>ちなみに、萩本さんはＭＶＣ、ＰＡＣとＢＣＥモデルを同じような次元で
>説明されていますけど、これって誤解を招きそう。
>このスレの皆さんはレベル高いからわかっていらっしゃると思いますが
>ＢＣＥはあくまでもＯＯＡにおける抽象モデルであって、
>ＭＶＣ、ＰＡＣのようなアーキテクチャとは視点が違うんじゃないでしょか。
>つまり、ＢＣＥでの分析モデルは、設計以降で適用されるアーキテクチャに
>対してニュートラルであって、特定のアーキテクチャを示すものではない
>と思うんですが、どーでしょう？

私もこの講演聴きました。クラスという細かい単位で設計する前にクラス
をおくための場に責務を与えて、その上にクラスを置くという話と、そも
そも設計課題がないままMVCを使うことはおかしいというような内容だっ
たように思いますが、この話には何ためらいもなくMVCを使っていた僕に
とっては目から鱗でした。

BCEも設計でも有効ですし、MVCもPACも特定のアーキテクチャには依存しな
いものだと思いますので、特に誤解をまねくものではないと思います。
ただPACについては、よくわからなかったので、この講演の後で萩本氏をお
っかけて質問しました。PACの場合はPACの３つでPACエージェントを構成す
るので本来ならこの中で比較するというのは適切ではないといわれていま
した。

何でみんなEVS Framework使わないの？
安いしイイのに。

>BCEも設計でも有効ですし、MVCもPACも特定のアーキテクチャには依存しな
>いものだと思いますので、特に誤解をまねくものではないと思います。
了解しました。
但し、分析モデルとしてのBCEにおける責務分担に対して、
設計モデルにおいて以下のアーキテクチャパターンを適用
した場合、それぞれにおける責務の微妙なズレをちゃんと理解
していないとまずいわけですね。
・smalltalk-MVC
・J2EE-MVC
・BCE
・PAC
話は戻りますが、日本製フレームワークってやっぱり
アーキテクチャ不在？

>>172
この会社はJ2EEの開発を行っているのですか？(藁

っで、フロントコントローラ系って何が幸せになるの？
デザイナーのオーサリングツールが使えなくて不便になるし
URLが同じになっちゃうんでServletTesterなどのServletの
ホワイトボックステストツール使いにくくなるし．．．
このバカな私に教えてやってください。

>>175
Servlet2.2以降対応のフロントコントローラなら、URL同じでなくても大丈夫じゃん。
何が幸せになるのかは微妙。フロントコントローラだけだと、アーキテクチャを縛ってくれることくらいかな。
ただアーキテクチャを縛っておくと、その上に便利な機能作りこめたりするのがいいかも。
StrutsのTaglibとか、Form自動解析/入力値再表示なんかはその例かと。
で。ServletTesterって何ですか？
それはServletUnitとかよりも遥かに幸せになれるもの？

Strutsがあるのに、なんで国産フレームワーク作る必要があるのか、ものすごーく疑問
もしかして、よっぽどヒマな人が多いと思われ（藁

あぼーん

>>177 既知外

なんかせっかく良スレになってきていたのに
勿体無いので正常化期待age

保守

ところで、
ServletやTaglibバリバリのフレームワークって、
Webサービス全盛になった時に役に立つのでしょうか ??

>>182

利用するスコープが違うからあんまり意味を持たない疑問の
ような気がするな。
182氏のいうフレームワークってStrutsとかのことでしょ？
人間が使うのがWebアプリフレームワークであって，
Webサービスを直接使用するのは人間じゃないよね。
単にStrutsにWebサービスクライアントのコードを直に
埋めるか，そのためのさらなるプロキシの仕組みを
入れればいいだけだと思う。

>>183
Webサービスをクライアント／サーバー技術として使うことも
十分あるんじゃないの？

>>184

そりゃあるよ。でもそれは182氏の疑問とは
また違った話でしょ。

それに，C/Sという位置付けということならWebアプリフレームワーク
とWebサービスアプリの関係と何も変わらないからそもそも意味的に
直交しないと思うのだが?

人間 <==> C/Sでのクライアントアプリ(Webサービスクライアント) <==> Webサービス提供側

人間 <==> WebアプリF/W(Webサービスクライアント) <==> Webサービス提供側

これってどうよ？いかにも使えそうにないサービスなんだけど。
http://www.jcreation.co.jp/venus/

>186
とうCOBOLとjavaをマッピングするのか書いていないだけに
眉唾っぽいなぁ。
特許出願中ってのも雑誌のあやしいペンダントの広告みたいだし

>>187
ＥＶＳ　Ｆｒａｍｅｗｏｒｋはそれ以下。
だって単にニュースリリースネタで発表しているんだもん。
自作自演企業（藁。

♪♪イーベンチャーサポート♪♪♪
www.evs.co.jp

社長池上は、

・ＡＳＰもダメ
　→わずか6ヶ月で撤退（結局、モノは出来なかった）

・Ｆrameworkもダメ
　→ニュースリリースは出したが、やっぱりモノは出来ていない

・人材派遣（それも違法請負派遣）
　→バカでも立ち上げやすい、違法請負派遣業にやっと落ち着く。でももうだめぽ


の３ダメ男。これはもう、逝け神ぽ。

皆さん、こんな会社にサポートされたいですか？
ｼｮﾎﾞｰﾝ━━(´･ω･`)━━

EVSはだめってことで、そろそろ新ねた。
株式会社テンアートニのWeb Developer Cafeってどうかな？
http://www.10art-ni.co.jp/product/WWB_Family/wwb-dc_index.html

見る限り……

>>190
HtmlFormESB？
Web層の責務をEJBになんで持ち込む必要があるんだ？
問い詰めたい！小一時間問い詰めたい！

>>192
何が悪い？

JDBCとかServletのラッパーを用意してよろこんでいるようなフレームワークって大抵
設計が古いよね。へんてこりんなＡＰＩ覚えるよりJDBCやServletのほうが
簡単なのに、うたい文句に踊らされる会社も多いんだよね。
結局わけわからんでフレームワークのトレーニングとかサポートで高ーい
お金払う目に．．．それでも気がつかんDQN会社も多し。

>>191

俺も同意
EJBってこういう使い方をそもそも想定してるもんではないような
気がするが…いやそりゃ動く動かないのレベルで困ることはないにしてもさ。

#画面遷移状態やリクエストパラメータのバリューオブジェクトへの変換が
#EJB層でってのは「?」だな

NECのOMEはどうですか？

>>194
動けばいいんじゃない？

>>196
それじゃフレームワークも糞もねーだろ。

http://homepage.mac.com/leverage/

今現在○○○FrameWorkの業務の要望にあわせてカスタマイズしています。
FrameWorkチームは業務側の要望を詳しく知らないし（俺）。。。
業務チームはFwを良く知らないし。
連携がまったく取れていなく、結構大変です。

むー。はい。愚痴です。

>>197
動作して、速くもの作れればいいじゃん？