LINQ to SQL 业务对象创建最佳实践
我在最近的项目中广泛使用了 LINQ,但是,我一直无法找到一种既不显得草率也不实用的处理对象的方法。
我还要指出的是,我主要使用 ASP.net。
我讨厌将数据上下文或 LINQ 返回类型公开给 UI 代码。我更喜欢对业务对象进行更细粒度的控制,而且它似乎与数据库耦合得太紧密,这不是一个好的实践。
以下是我尝试过的方法..
将项目项目放入自定义类
dc.TableName.Select(λ => new MyCustomClass(λ.ID, λ.Name, λ.Monkey)).ToList();
这显然会导致大量用于创建、更新等的接线代码...
围绕返回创建包装器object
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 语句中,重要的是转换而不是变量 -不确定这是否有意义,但是等等,
抱歉这个很长的问题。 预先感谢您的投入,祝新年快乐!
I've been using LINQ extensively in my recent projects, however, I have not been able to find a way of dealing with objects that doesn't either seem sloppy or impractical.
I'll also note that I primarily work with ASP.net.
I hate the idea of exposing the my data context or LINQ returned types to my UI code. I prefer finer grained control over my business objects, and it also seems too tightly coupled to the db to be good practice.
Here are the approaches I've tried ..
Project items into a custom class
dc.TableName.Select(λ => new MyCustomClass(λ.ID, λ.Name, λ.Monkey)).ToList();
This obviously tends to result in a lot of wireup code for creating, updating etc...
Creating a wrapper around returned object
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();
Seems to work pretty well but reattaching for updates seems to be nigh impossible somewhat defeating the purpose.
I also tend to like using LINQ Queries for transformations and such through my code and I'm worried about a speed hit with this method, although I haven't tried it with large enough sets to confirm yet.
Creating a wrapper around returned object while persisting data context
public class MyCustomClass
{
LinqClassName _core;
MyDataContext _dc;
...
}
Persisting the data context within my object greatly simplifies updates but seems like a lot of overhead especially when utilizing session state.
A quick Note: I know the usage of λ is not mathematically correct here - I tend to use it for my bound variable because it stands out visually, and in most lambda statements it is the transformation that is important not the variable - not sure if that makes any sense but blah
Sorry for the extremely long question.
Thanks in advance for your input and Happy New Years!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我在从 LINQ 查询返回的表上创建“Map”扩展函数。 Map 函数返回一个普通的旧 CLR 对象。例如:
然后,您可以将 Map 函数添加到 LINQ 查询中的选择列表,并让 LINQ 返回 CLR 对象,如下所示:
如果要返回列表,则可以使用 ToList 来获取 List<> 。后退。如果您更喜欢创建自己的列表类型,则需要做两件事。首先,创建一个采用 IEnumerable<> 的构造函数。基础类型的,因为它是一个参数。该构造函数应该从 IEnumerable<> 复制项目。收藏。其次,创建一个静态扩展方法以从 LINQ 查询调用该构造函数:
创建这些方法后,它们会隐藏在后台。它们不会使 LINQ 查询变得混乱,也不会限制您可以在查询中执行的操作。
此博客 条目有更详尽的解释。
I create "Map" extension functions on the tables returning from the LINQ queries. The Map function returns a plain old CLR object. For example:
You can then add the Map function to the select list in the LINQ query and have LINQ return the CLR Object like:
If you are returning a list, you can use the ToList to get a List<> back. If you prefer to create your own list types, you need to do two things. First, create a constructor that takes an IEnumerable<> of the underlying type as it's one argument. That constructor should copy the items from the IEnumerable<> collection. Second, create a static extension method to call that constructor from the LINQ query:
Once these methods are created, they kind of hide in the background. They don't clutter up the LINQ queries and they don't limit what operations you can perform in teh query.
This blog entry has a more thorough explanation.