2
私は現在、多少の広範な通信プロトコルを扱いやすいものに改造しています。これは一種の疑問な質問ですが、あなたの経験に基づいて、コードがますます大きくなるにつれてこれら2つのアイデアのどちらを維持するのが簡単です。通信プロトコルの保守性 - 重複または個々の要求？
クライアントとサーバーがあります。サーバーには、クライアントが望む情報A、B、C、Dなどがあります。情報は名前のような単一のデータセットではなく、名前のリストです。一般的に列の内容全体。クライアントは一般的に、ABC、DEF、ABDなどのようなグループでこのようなものを必要とします。オーバーラップはありません（つまり、Aの要求の80％はBとCの要求です）。
システムが大きく成長するにつれ、それが簡単に通信プロトコルは同じように動作し、システムを維持することです：
Request 1: Server returns ABC
Request 2: Server returns ABD
または
Request 1: A
Request 2: B
Request 3: C
など
私はと行くに傾いています最初のコードは、コードを読みやすく、扱いやすくするためで、ABCのようなグループの特別な要求を持つことで、サーバーがデータベースに対して実行するクエリが少なくなることがありますo必要な情報を入手する。しかし、コードベースは現在よりも大幅に大きくなり、クライアントとサーバーがどのように通信しているかを見直す時間が既にかかっているので、ここの人々が/または方法で持っていた経験を聞きたかった。
編集： 私はネットワークトラフィックだけでなく、サーバーがこれらの要求をどのように処理するかといったことについても言及しています。クライアントが3つの個別の要求を行う場合、サーバーは3つのDBクエリを作成する必要があります。グループ化された要求は単一のクエリとして実行される可能性が最も高いからです。
はい、最初の方法を使用しないと、サーバはA、B、Cをクエリする必要があることを知ることができ、（ストアドプロシージャなどを使用して）一度にすべて実行できます3つの別々のクエリを実行します。あなたが言ったように、ボトルネックはデータベースにある可能性が高い、それは私が言及しているものです。クライアントが3つの別々のプロトコル要求を行う場合、サーバーはそれらを一緒にグループ化する方法を知りませんので、3つのDBクエリを作成する必要があります。 – cost
私は同意して、最初の方法で行くと言っています。実際には、これは主な決定要因です。「コードを読みやすく、扱いやすくするため、最初のコードと一緒に行く傾向があります。 – yamen
オハイオ州、私はそこに少しあなたを誤解しました – cost