|
问题描述：
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.
| 
转播
