私は最近のプロジェクトで LINQ を広範囲に使用してきましたが、ずさんでも非実用的でもないオブジェクトを処理する方法を見つけることができませんでした。
また、私は主に ASP.net を使用していることにも注意してください。
データ コンテキストまたは LINQ が返す型を UI コードに公開するという考えは嫌いです。私は自分のビジネス オブジェクトをよりきめ細かく制御することを好みます。また、データベースとの結合が強すぎて、適切な方法とは言えません。
ここに私が試したアプローチがあります..
項目をカスタム クラスに射影する
dc.TableName.Select(λ => new MyCustomClass(λ.ID, λ.Name, λ.Monkey)).ToList();
これは明らかに、作成、更新などのための多くのワイヤーアップ コードになる傾向があります...
返されたオブジェクトのラッパーを作成する
public class MyCustomClass
{
LinqClassName _core;
Internal MyCustomClass(LINQClassName blah)
{
_core = blah;
}
int ID {get { return _core.ID;}}
string Name { get {return _core.Name;} set {_core.Name = value;} }
}
...
dc.TableName.Select(λ => new MyCustomClass(λ)).ToList();
かなりうまく機能しているようですが、更新のために再接続することはほぼ不可能のようで、目的に反しています。
また、コードを介して変換などにLINQクエリを使用するのが好きな傾向があり、まだ確認するのに十分な大きさのセットで試していませんが、この方法で速度が低下することを心配しています。
データ コンテキストを保持しながら、返されたオブジェクトのラッパーを作成する
public class MyCustomClass
{
LinqClassName _core;
MyDataContext _dc;
...
}
オブジェクト内でデータ コンテキストを永続化すると、更新が大幅に簡素化されますが、特にセッション状態を利用する場合は、多くのオーバーヘッドが発生するようです。
簡単なメモ: ここで λ の使用法が数学的に正しくないことはわかっています。視覚的に目立つため、バインドされた変数に使用する傾向があり、ほとんどのラムダステートメントでは変数ではなく変換が重要です。それは意味がありますが、何とか
非常に長い質問で申し訳ありません。ご意見をお寄せいただきありがとうございます。明けましておめでとうございます。