だから私はこれを機能させました、ここに私が持っているものがあります:
internal SomeInternalPOCOWrapper FindXXX(string xxx)
{
Condition.Requires(xxx).IsNotNullOrEmpty();
var someInternalPokey = new SomeInternalPOCOWrapper();
var ctx = (this as IObjectContextAdapter).ObjectContext;
var con = new SqlConnection("xxxxx");
{
con.Open();
DbCommand cmd = con.CreateCommand();
cmd.CommandText = "exec dbo.usp_XXX @xxxx";
cmd.Parameters.Add(new SqlParameter("xxxx", xxx));
using (var rdr = cmd.ExecuteReader())
{
// -- RESULT SET #1
someInternalPokey.Prop1 = ctx.Translate<InternalPoco1>(rdr);
// -- RESULT SET #2
rdr.NextResult();
someInternalPokey.Prop2 = ctx.Translate<InternalPoco2>(rdr);
// -- RESULT SET #3
rdr.NextResult();
someInternalPokey.Prop3 = ctx.Translate<InternalPoco3>(rdr);
// RESULT SET #4
rdr.NextResult();
someInternalPokey.Prop4 = ctx.Translate<InternalPoco4>(rdr);
}
con.Close();
}
return someInternalPokey;
}
基本的には、従来の ADO.NET に似ています。を読み、DbReader
次の結果セットに進みます。
しかし、少なくともTranslate
、結果セット フィールドと提供されたエンティティとの間で左から右に処理するように見えるメソッドがあります。
メソッドは内部的なものであることに注意してください。
My Repository はこのメソッドを呼び出し、DTO をドメイン オブジェクトにハイドレートします。
私は 3 つの理由で 100% 満足していません。
DbContext
asをキャストする必要がありIObjectContextAdapter
ます。メソッドTranslate
はDbContext<T>
クラス IMO にある必要があります。
- 従来の ADO.NET オブジェクトを使用する必要があります。なんで?ストアド プロシージャは、すべての ORMに必須です。EF に対する私の主な不満は、ストアド プロシージャのサポートがないことであり、これは EF CTP5 では修正されていないようです。
- 新しい SqlConnection を開く必要があります。EF Context によって開かれた接続と同じ接続を使用できないのはなぜですか?
これが誰かを助け、EF チームにメッセージを送ることを願っています。既製の SPROCS では、複数の結果をサポートする必要があります。ストアド プロシージャを複合型にマップできるのに、なぜストアド プロシージャを複数の複合型にマップできないのでしょうか。