- - PR -
ミドルウェアを使用できない環境でのC/S通信の選択肢
投稿者 | 投稿内容 | ||||||||
---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2006-07-29 17:41
ちなみに
は、どうしてなんでしょう? 差し支えなければ教えてほしいです。 例えばですが、クライアント環境の汚染とかそういうのが問題なら、アプリケーション実行をサーバ機に集中させてしまって、RDP や MetaFrame でアクセスする、なんてのもありですかね? | ||||||||
|
投稿日時: 2006-07-29 18:09
>検索結果はページング処理して、5000件程度を返す予定です。
1件あたりの表示データ数にもよるとは思うのですが、普通の サーバサイド側でHTML生成する形式の場合、1ページあたりの データ数が多すぎると思いますよ。どの形式でデータ取得を行う 場合でも、件数は3桁のしかもなるべく小さい数に抑えた上で 検討した方が、偏った評価にならず済むと思います。 XMLで柔軟性を持たせつつ、レスポンスもある程度確保したい 場合でも、件数を抑えることで実現できこともあるでしょうし。 | ||||||||
|
投稿日時: 2006-07-30 14:37
私も気になります。どこから出てきた要求なんでしょう? ありがちなのは、この要求を一生懸命守って苦労して開発してから、後でその要求の当人に聞いたら「俺そんなこと言ったっけ?まあ、インストールが簡単なほうがいい、とは言ったかな?」という程度だったら悲しいですね。 なお、もし Java だったら JRE と自前のクラスファイルや jar ファイルを一括してインストール先のフォルダーにコピーするだけ、というインストール形態もたまに見かけます。 -- unibon {B73D0144-CD2A-11DA-8E06-0050DA15BC86} | ||||||||
|
投稿日時: 2006-07-30 19:15
5000件程度 返して その後ユーザーはどうするんです? 通常なんらかの抽出処理をして 100件程度にして返しますが | ||||||||
|
投稿日時: 2006-07-30 21:03
件数は程度問題ではないでしょうか。 たとえば、とある掲示板のビューアーだと、一度に数百件ぐらいやりとりします。リッチなクライアントなら、数千件位はザラにあると思います。マウスのホイールなどでガーっとスクロールしながら一気に目を通すような使い方なら数千件位は一度に返してほしいこともかなりあります。スクロールバーの付いたテーブルやリストボックスに返すデーターなら、件数は数万件くらいまであってもおかしくないのではないでしょうか。 もちろん、やみくもにたくさん返すのも問題ですが、なんでその件数で制限しちゃうの?と悩むような意義の分からない件数制限があると、使い勝手が悪くなると思います。ネットワークなどの物理的な限界による制限もあるとは思います。 -- unibon {B73D0144-CD2A-11DA-8E06-0050DA15BC86} | ||||||||
|
投稿日時: 2006-07-31 12:42
> 差し支えなければ教えてほしいです。
> は、どうしてなんでしょう? 都合上詳しいことは書けないのですが、 おおまかに言えば大手メーカーシステムの 端末に同居する形でクライアントが使われる事が ほとんど、というのが理由です。 大抵の場合なんらかのミドルウェアを新規 でインストールするのは非常に嫌がられます。 (ユーザーはOKを出してもメーカがNGだと インストールはできないわけです) 上記の理由でクライアント環境を汚さないように、 ということになっているのですが。。。 > 5000件程度 返して その後ユーザーはどうするんです? > 通常なんらかの抽出処理をして 100件程度にして返しますが > 件数は程度問題ではないでしょうか。 > たとえば、とある掲示板のビューアーだと、一度に数百件ぐらいやりとりします。リ > ッチなクライアントなら、数千件位はザラにあると思います。マウスのホイールなど > でガーっとスクロールしながら一気に目を通すような使い方なら数千件位は一度に返 > してほしいこともかなりあります。スクロールバーの付いたテーブルやリストボック > スに返すデーターなら、件数は数万件くらいまであってもおかしくないのではないで > しょうか。 頭の中ではリッチクライアント(というはファットクライアント)のリストボックスを 想定していました。 ただし件数に関しては既存のシステムがこの件数で制限していたので、というのがあり ます。制限がきつくなるというのは目立つのでユーザーは嫌がるのではないかなぁ、 と。。。 |