DLINQ 使用DataContext快速构建数据访问层DAL,发现Updata采用Attach(Entity t,true)困难重重！（如果实体声明了版本成员或者没有更新检查策略，则只能将它附加为没有原始状态的已修改实体）的解决办法！

问题描述：

1.使用DataContext快速构建数据访问层DAL

2.可能UI层用到了如：System.Web.UI.WebControls.Gridview;

3.当然要实现增删改查功能了!

发现问题:

今天去书店逛逛，又听到人在讨论Linq已死!我就站在边上听了听，他们谈到了上面的问题，说

DLinq DataContext 提供的Attach(Entity t,true)无法实现更新操作！什么狗屁API！然后是对Linq性能的一顿抨击！（其实，我理解是对DLinq数据访问效率的质疑！）

问题跟踪:

想起自己也碰到过这个问题，当时用了5分钟时间思考，现在觉得可能对大家有帮助！

当你在上面问题的场景中，出现这中情况 ,如下：

InvaildOperationException:如果实体声明了版本成员或者没有更新检查策略，则只能将它附加为没有原始状态的已修改实体。

解决办法:

1.不使用Attach()方法实现Updata

2.使用Context对象.DeleteOnSubmit(temp);//删除对象

         Context对象.SubmitChanges();//更新

3.删除实体，这是后仍在内存的中存在

   使用Context对象.InsertOnSubmit(temp);//添加对象

         Context对对象.SubmitChanges();//更新对象

思考：

1.Attac()方法，有它特定的使用场景，这不应该是API设计问题！版本策略问题，咱讨论不了！

2.简单的CRUD问题，就用简单的增删改查方法实现就好了。谁说Updata必须要自己独立的数据库操作方法！

3.性能问题：

3.1DLinq不是Linq只是Linq的一部分。DLinq只适用.Net IDE和MSSql产品搭建的系统环境。它的主要思想还是提供：简化，快速，直观，方便，当然有商业目的。

3.2多次操作数据库，构建多个数据访问实体！确实是影响性能的！但是，牺牲性能和提高运行效率这是要综合判断的！让架构和技术主管去考虑吧！

3.3Ado.Net断开是连接，理解透彻了。对多次数据库连接与访问性能问题就会认识深一点点。

3.4如果应用系统后台数据库是MSSql,而且不会变化。那么，DLinq确实用优势！

3.5如果，数据访问层明确会发生变化，那么请在访问层适用工厂模式。如果客户是急性子，要先看到项目的大模样，那么DLinq还是有用的。

3.6如果，业务逻辑频繁变动，数据库不变化，DLinq更新一下dbml文件，其他的你不用修改！

3.7如果，业务逻辑频繁变动，数据库也可能是MSSql,Orcale,MySql.DB2间频繁变更，那你一开始就对系统框架考虑的不够。也并不是说你需要做复杂的系统架构工作。请在DAL,BLL间适用接口与抽象工厂模式，其实并不复杂！

3.8如果，3.7环境问题，你已经考虑明白，有了解决办法。那么DLinq在零代码开发和急性子用户间仍可以帮到你。因为这时候，DLinq提供的只是一种实现功能！

3.9我从来没觉得一个系统，必须适用一个DAL数据访问层。对于电子政务（政绩项目），电子商城的B2C等环境中，数据访问量不大，操作频率不高，而你恰好碰到了MSSQL数据库，ASP.NET项目几率很高吧！那么，建议你在适当的情况下适用DLinq.