これを得ました：
var ApprovalRoleRefList = db.ApprovalRoles.Select(x => x.ApprovalRoleName);
var CostDivisionRefList = db.CostDivisions.Select(x => x.CostDivisionName);
linq を使用した DB への 1 回の呼び出しでこれが必要な場合は、どうすればよいですか?
これは私が望むものではありません:
var lists = (from ar in db.ApprovalRoles select ar.ApprovalRoleName).Concat (
from cd in db.CostDivisions select cd.CostDivisionName);
プロジェクトでは、さらに 3 つのリストを取得しましたが、呼び出しが 1 つなのか 5 つなのかは「パフォーマンスが悪い」のでしょうか? この部分があまり使われないことはわかっていますが、最適化するのは楽しいです。
ジョンは非常に良い点を指摘したと言わざるを得ないので、ここでそれについて話します. 明らかに、1 回以上の往復を行うと、5 回行うよりも費用がかかりますが、それは単純なレベルに過ぎません。さらに、この機能がまったく必要ないというわけでもありません。実際に Stack Overflow で使用されているDapperを検討してください。これには、探しているものを正確に実行する機能があります。したがって、機能が存在するという事実は、Stack Overflow でさえ、ある時点でこれを行う必要があったことを示しています。
ただし、スタック オーバーフローのニーズと自分自身を比較する前に、スタック オーバーフローがこの機能を必要とした理由を考えてみましょう。2010 年の時点で、1 日あたり約 150 万件のヒットがありました。まあ、必要な数のヒットを取得している場合は、さまざまなテクニックを使用する必要がありますが、1回の往復を行うのは、それらのテクニックの中で最も少ない方法です。極端なキャッシング、負荷分散、サーバー ファーム、分散コンピューティングなど、リストは延々と続きます。
要するに、アプリケーションを完全に理解していなくても、1 日に何百万もの読み取りと書き込みを発行するスタック オーバーフローのボートに陥らない限り、文字通り何の変化ももたらさないものを最適化していると言えます。したがって、5 往復が正しいアプローチです。
1つのリクエストで結果を返す必要がある場合、LINQtoSQLはストアドプロシージャからの複数の結果セットをサポートします。http://www.thinqlinq.com/Post.aspx/Title/Using-LINQ-to-SQL-to-return-Multiple-Resultsを見て、それがニーズを満たすかどうかを確認してください。