新しいGWTアプリケーションを開始し、誰かの経験からアドバイスを得ることができるかどうか疑問に思っています。
RPCサービスを介して多くのサーバー側機能が必要です...しかし、どこに線を引くのか疑問に思っています。
小さな電話ごとにサービスを提供することも、より多くの操作を処理するサービスをより少なくすることもできます。
私が顧客、ベンダー、および管理サービスを持っているとしましょう。各カテゴリーの機能ごとに3つのサービスまたは1つのサービスを作成できました。
サービスの実装の多くはコンパイル時のヘルプを提供せず、場合によっては実行するのが面倒であることに気付きましたが、それは優れたモジュール性を提供します。より大きなサービスを使用している場合、説明したようなモジュール性はありませんが、サービスの作成の問題を解決したり、web.xmlファイルのエントリを減らしたりする必要はありません。
多くのサービスの使用にリソースの問題はありますか？使用する粒度のレベルを決定するためのベストプラクティスは何ですか？
私の意見では、「論理的な」もののためにrpcサービスを作成する必要があります。あなたの例では：
1つは顧客用、もう1つはベンダー用、3つ目は管理者用です。
このようにして、いくつかのサービスを意味ごとにグループ化しておくことができ、web.xmlファイルで維持する行が数行になります（これは朗報です:-)
さらに深刻なことに、rpcサービスは通常、データベースのものを呼び出すためのラッパーであるため、単一のweb.xmlエントリと数千の操作で単一の「MagicBlackBoxRpc」を作成することもできます。
しかし、あなたが提案するように、管理操作用に別のrpcを作成することは良いことのようです。
適切なソフトウェアエンジニアリングの本にある「クラスの大きさ」に関する一般的なアドバイスを読んでください。
私の意見では：
1つのクラス=1つのサブジェクト（つまり、関連する機能または動作のグループ）
クラスは複数の主題を扱うべきではありません。例えば：
クラスPersonDao->件名：DBとJavaコード間のインターフェース。
実行されません：-Personインスタンスをキャッシュします-フィールドを自動的に更新します（たとえば、フィールド'lastModified'を更新します）-データベースを検索します
なんで？
他のすべてのことのために、それをしている他のクラスがあるでしょう！それぞれ：-PersonDaoの周りのキャッシュは、必要以上に頻繁にDBにアクセスすることを避けるために、情報の効率的なストレージに関係しています-DAOを使用するサービスクラスは、自動的に変更する必要があるものすべてを変更する責任があります。-データベースを見つけることはデータソース（通常はSpringのようなフレームワークの一部）の責任であり、Daoはそれについて心配する必要はありません。それはその主題の一部ではありません。
TDDがその答えです
この種の分離の必要性は、TDD（テスト駆動開発）を行うときに非常に明確になります。単一のクラスがあらゆる種類のことを行う悪いコードでTDDを実行してみてください！1つの単体テストを開始することすらできません！これが私の最後のヒントです。TDDを使用すると、クラスの大きさがわかります。
最適化するのは、サーバーへの1回のラウンドトリップで結果を達成できることだと思います。サービスオブジェクトにアドホックなメソッドのコレクションがあります。クライアントが何かを実行する必要があるときに、状況ごとに1つずつです。ユーザーがサーバーに座って待機しているときに、クライアントがサーバーに連続してRPCを実行することは望ましくありません。
RESTは物事を直交させますが、直交性にはコストがかかります。言語で頻繁に使用される動詞が不規則である理由があります。アプリに対してクリーンな直交構造を維持するという観点から、スキーマが適切に設計されていることを確認してください。ここで、各クラスは他のクラスのセマンティクスと直交するセマンティクスを持つ必要があります。各RPC呼び出しのセマンティクスをスキーマで明確に記述することができれば、RESTで完全に理想的でなくても、それらが何を意味するかについて混乱することはありません。