在我最近的项目中,我一直在广泛使用 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;
...
}
在我的对象中保留数据上下文极大地简化了更新,但似乎开销很大,尤其是在使用会话状态时。
快速注意:我知道 λ 的使用在这里在数学上是不正确的——我倾向于将它用于我的绑定变量,因为它在视觉上很突出,在大多数 lambda 语句中,重要的是转换而不是变量——不确定是否这有任何意义,但废话
很抱歉这个问题很长。提前感谢您的投入和新年快乐!