Linq 都出来了，自己搞数据访问架构还有意义吗？

[bluedoctor]

自己潜心搞了两年，最近三个月才有机会使用的数据访问架构，结合ORM和iBatis的数据访问架构，觉得还不错，可是最近看到了MS的VS2008里面都有Linq了，觉得自己的东西好像意义不大了。
Linq 都出来了，自己搞数据访问架构还有意义吗？

[bluedoctor]

比如,数据插入的语法：
object insertValue=null;
xb.CurrentDataBase.Insert (
bl.Select (
bl.Add ( bl.F_AcceptDate )
.Add (bl.F_Accepter )
.Add (bl.F_BusinessID )
.Add (bl.F_ModuleID )
.Add (bl.F_NodeID )
.Add (bl.F_Remark )
.Add (bl.F_State )
//.Add (bl.F_SuccessDate )
//.Add (bl.F_SuccessMan )
)
,ref insertValue);

数据更新的语法：

xb.CurrentDataBase.Update (
bt.Select (
bt.Add (bt.F_AccepterList )
.Add (bt.F_CheckMan )
.Add (bt.F_Curr_ModuleID )
.Add (bt.F_Curr_NodeID )
.Add (bt.F_State )
.Add (bt.F_BTID )
.Add (bt.F_AssignMan )
.Add (bt.F_AssignDate )
.Add (bt.F_ChkEDate )
.Add (bt.F_ChkSDate )
.Add (bt.F_OptSDate )
.Add (bt.F_OptEDate )
)
);

[bluedoctor]

整个修改，插入，选择，都可以更新部分字段的，这是我自己搞ORM的主要原因。另外，也可以使用SQLMapper方式，将查询结果映射到一个对象中，
/// <summary>
/// 根据业务号获取业务任务
/// </summary>
/// <param name="BusinessID"></param>
/// <returns></returns>
public BusinessTask GetBusinessTask(Int32 BusinessID )
{
//获取命令信息
Mapper.GetCommandInfo("GetBusinessTask");
//参数赋值，推荐使用该种方式；
Mapper.DataParameters[0].Value = BusinessID;
//参数赋值，使用命名方式；
//Mapper.SetParameterValue("@BusinessID", BusinessID);
//执行查询
return (BusinessTask)Mapper.ResultMapEntity( CurrentDataBase.DAO.ExecuteReader(CurrentDataBase.ConnectionString, Mapper.CommandType, Mapper.CommandText , Mapper.DataParameters), new BusinessTask() );
//
}//End Function

[jzywh]

你能用LINQ解决所有问题么？

[IcyPlayer]

linq在解决一些比较直接的问题时确实很方便，不过有些访问数据库的重复复杂操作还是需要自己的框架封装一些方法以求更方便，小弟我愚见，呵呵

[ld_thinking]

适合自己的才是最好的

[变成熊猫你就老实了是不]

就像是GriView都出来了，搞分页还有意义吗
ADO.NET都出来，搞数据访问层还有意义吗

[大腹]

[Quote=引用 9 楼 isline 的回复:]
就像是GriView都出来了，搞分页还有意义吗
ADO.NET都出来，搞数据访问层还有意义吗
[/Quote]
明白鸟明白鸟...

[aierong]

没有绝对的

适合自己的最好

[一品梅]

没接触过LINQ,
当然有意义,见多识广吗?
没听说过懂LINQ的,以前的基础知识不精通熟炼的.

[bluedoctor]

还有几位星星来发言阿，谢谢，想多听听大家的看法。

[kkk_visual]

以后的程序员就是在做流水线，很多时候不理解内部的原理。我个人认为不管现在有多么的方便，如果是要走程序员这条路的，最好还是试着自己做一些，等原理明白了，再用现成的会更好。

[bluedoctor]

感谢sp1234,真是热心的大牛啊！

[以专业开发人员为伍]

[Quote=引用 2 楼 bluedoctor 的回复:]
整个修改，插入，选择，都可以更新部分字段的，这是我自己搞ORM的主要原因。另外，也可以使用SQLMapper方式，将查询结果映射到一个对象中，
/// <summary>
/// 根据业务号获取业务任务
/// </summary>
/// <param name="BusinessID"> </param>
/// <returns> </returns>
public BusinessTask GetBusinessTask(Int32 BusinessID )
{
//获取命令信息
Mapper.GetCommandInfo("GetBusinessTask");
//参数赋值，推荐使用该种方式；
Mapper.DataParameters[0].Value = BusinessID;
//参数赋值，使用命名方式；
//Mapper.SetParameterValue("@BusinessID", BusinessID);
//执行查询
return (BusinessTask)Mapper.ResultMapEntity( CurrentDataBase.DAO.ExecuteReader(CurrentDataBase.ConnectionString, Mapper.CommandType, Mapper.CommandText , Mapper.DataParameters), new BusinessTask() );
//
}//End Function
[/Quote]

Linq是“整个修改，插入，选择，都可以更新整个对象的”。

你搞的那个整个还是关系数据库操作风格。

ORM不应该仅仅在关系数据库上做一点表面文章，而应该从OO风格出发。我总结了几条ORM用例。

[以专业开发人员为伍]

编程，就应该追求“一行或者尽量少的代码来实现一个需求”这种目标。ORM正是为了简化对象的处理而产生的，用户无需关心如何将对象拆分为零碎的底层代码。你要求用户对对象的操作拆分写为对字段的操作，这是反ORM的做法。

至于认为越是高级、成熟的框架越不应该使用，我是很反对这种看法的。固然，现学现卖地使用那些成熟框架程序的做法可以蔑视，但是认为越是低级的代码越高级也同样害人。越是高级的东西越应该多多创造使用它的机会，不要纠缠于低级的东西多么“效率高、教育人”。毕竟，软件是用来用的，而不仅仅是用来学的。

[以专业开发人员为伍]

ORM最初、最基本的功能，就是在程序员的代码中类似“db.Save((User)MyObject);”这样地，将一个由变量MyObject所指引的（User）对象一步到位地更新到数据库中去。至于采取什么方式，是写配置文件还是自动反射（对每种类型最多仅需要反射一次），等等解析方式，这并不重要。重要的是：不能再让用户的程序中更新对象时再写过分累赘的字段处理代码。

如果你做不到，Linq做到了，这个最最基本的功能，那么就足以证明应该放弃你自己的“ORM”而使用Linq了。

[以专业开发人员为伍]

Linq是开源项目，也有很多Linq源代码的分析文章。此外，有很多种Linq。Linq是一个可以发挥你自己的想象力去设计provider的框架，有更广阔的扩展空间给你创造自己的商品化衍生产品。

[以专业开发人员为伍]

上面的链接中的内容比较少，我随便google了一下，看到http://blog.miniasp.com/post/2007/12/Learn-LINQ-From-Here.aspx。