问题：ASPNET 留言功能，怎么把textbox中的数据存到数据库？！
描述:怎么把textbox中的数据存到数据库？！
求一段详细代码！！！求大神帮忙，马上交作业，还是写不出来这个功能！！！解决方案1:得看你用的是mvc还是控件，不一样的.解决方案2:提交按钮的单击事件里写代码，SqlConnection conn = new SqlConnection("连接字符串");
string sql="SQL语句"；
SqlCommand cmd = new SqlCommand(sql, conn);
int row=cmd.ExecuteScalar();
}解决方案3:ado.net、linq to sql、entity framework都可以解决方案4:在提交按钮的click事件里，连接数据库，并写insert语句写进数据库。最基本的操作，可以去百度。解决方案5:在提交按钮里面写 就是insert语句就行啦 value 里面的值格式' "+textbox1.text" '解决方案6:最简单的
string sql = string.Format("insert into 你的表(姓名, 标题, 内容) values(\"{0}\", \"{1}\", \"{2}\")", textBox1.Text, textBox2.Text, textBox3.Text);
SqlConnection conn = new SqlConnection("连接字符串");
SqlCommand cmd = new SqlCommand(sql, conn);
cmd.ExecuteScalar();
以上介绍了“ASPNET 留言功能，怎么把textbox中的数据存到数据库？！”的问题解答，希望对有需要的网友有所帮助。
本文网址链接：/wd/634009.html
上一篇： 下一篇：&&& 最近一年的项目，我主要负责一些小型项目(就是指企业内部的小项目)，在数据库操作方面我们采用了以开发速度快为特点的Linq to Entity，这里我不多讲它的使用方法，先来分享下我认为还不错的几个地方：&&&&&&& 1:某种情况下可以完全代替传统SQL开发&&&&& 这里是指比较简单的数据库处理，比如查询，几个表关联查询及添加数据，更新数据，删除数据等，不包含特别复杂的事务处理或者业务逻辑特别复杂的小型报表之类的处理，为此不需要员工一定会SQL语句的开发。&&&&& &&& 2:性能上也是能接受的&&&&& 现在的Entity Framework5，微软已经做出大量的优化工作，专门针对如何生成查询更优的SQL语句做了大量努力,且一般小型项目也不会存在特别大的性能问题。大家发现问题了可以看下生成的SQL做特殊优化即可。&&&&& &&& 3:简化了开发过程&&&&& 一般情况下，我们首先需要将数据库表数据加载成DataReader或者是DataTable，然后再转换成我们的业务数据Model，有了EntityFrame work，它已经自动完成了此部分的转换。&&&&& &&& 问题：&&&&&&&&&& 如何处理数据库Model以及业务数据Model表达式之间的转换?&&&&&&& 什么是数据库Model？&&& &&&&&&&&& 当我们采用数据库优先方式创建了一个edmx文件后，它会生成和数据库表名一样的数据库Model，比如我这里的DataAccess.ActionInfo&&& &&& 什么是业务数据Model？&&&&&&&& 真正的业务系统中，是不能直接使用系统自动生成的Model的，原因如下：&&& &&& 1：这些代码是生动生成的，随时会发生改变,稳定性太差。&&& 2：数据库Model完全和数据库表对应，而业务数据Model有可能和数据库模型不完全一致,或者完全不一样。业务数据Model是处理业务逻辑的一个数据载体，由它解析成不同的数据库Model，最近进行数据库操作。比如我这里的ObjectModel.ActionInfo&&& &&& 前几篇文章中(我所理解的IRepository(续) ,我所理解的IRepository )，我提到我们项目中定义了如下仓储接口用于数据库查询。&&&&IList&T&&QueryByPage&TKey&(Expression&Func&T,&bool&&&filter,&Expression&Func&T,&TKey&&&orderBy,int&orderType,&int&pageSize,&int&pageIndex,&out&int&recordsCount);&&&&&&& 它的条件接受一个表达式，由于UI屋以及业务逻辑层均只能调用业务数据Model，当进行数据库查询时，EntityFramwork只能接受参数类型为数据库Model的对象，所以这里我们需要将类型为业务数据Model的表达式能够自动的转换成数据库Model类型的表达式。&&& &&& 比如我们在UI层可以这样查询数据,这里p的类型是业务数据Model&&&&service.QueryByPage(p&=&&(p.IsActive&&&&p.FunctionInfoId&==&FunctionInfoId.Value),&p&=&&p.Id,&1,&pageSize,&pageIndex.Value&+&1,&out&recordCount);&&&&&&& 下面是我们的业务数据Model,包含一些MVC的数据验证特性标签，同时字段数量上也和表字段不相同。&&&&View Code public&class&ActionInfo&&&&{&&&&&&&&#region&Primitive&Properties&&&&&&&&[Required(ErrorMessageResourceName="ValidationMessageNameRequired",&ErrorMessageResourceType=typeof(ActionInfoResources))]&&&&&&&&public&virtual&string&&Name&&&&&&&&{&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&}&&&&&&&&&&&&&&&&&[Required(ErrorMessageResourceName="ValidationMessageIsActiveRequired",&ErrorMessageResourceType=typeof(ActionInfoResources))]&&&&&&&&public&virtual&bool&&IsActive&&&&&&&&{&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&}&&&&&&&&&&&public&virtual&int&&Id&&&&&&&&{&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&}&&&&&&&&&&&[Required(ErrorMessageResourceName="ValidationMessageFunctionInfoNameRequired",&ErrorMessageResourceType=typeof(ActionInfoResources))]&&&&&&&&public&virtual&int&&FunctionInfoId&&&&&&&&{&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&}&&&&&&&&&&&[Required(ErrorMessageResourceName="ValidationMessageActionNameRequired",&ErrorMessageResourceType=typeof(ActionInfoResources))]&&&&&&&&public&virtual&string&&ActionName&&&&&&&&{&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&}&&&&&&&&&&&&&&&&&&&#endregion&&&&&&&&&&&#region&Navigation&Properties&&&&&&&&public&virtual&FunctionInfo&&FunctionInfo&&&&&&&&{&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&}&&&&&&&&&&&#endregion&&&&}&&&&&&&&& 下面是生成的数据库Model,代码较多，这里就贴一个属性内容，主要都是些和数据相关的内容，比如外键关系等：&&&&[EdmScalarPropertyAttribute(EntityKeyProperty=false,&IsNullable=false)]&&&&&&&&[DataMemberAttribute()]&&&&&&&&public&global::System.String&Name&&&&&&&&{&&&&&&&&&&&&get&&&&&&&&&&&&{&&&&&&&&&&&&&&&&return&_N&&&&&&&&&&&&}&&&&&&&&&&&&set&&&&&&&&&&&&{&&&&&&&&&&&&&&&&OnNameChanging(value);&&&&&&&&&&&&&&&&ReportPropertyChanging("Name");&&&&&&&&&&&&&&&&_Name&=&StructuralObject.SetValidValue(value,&false);&&&&&&&&&&&&&&&&ReportPropertyChanged("Name");&&&&&&&&&&&&&&&&OnNameChanged();&&&&&&&&&&&&}&&&&&&&&}&&&&&&&&&&&&&&& 我们需要一个工具类能够完成这两种不同类型的表达式之间的类型转换，需要满足如下需求：&&&&&&& &&&&&&& 1:最简单的表达式条件&&&&&&&&& 对属性做直接的条件比较，比如：等于，不等于，大于，小于，或 这里二元操作符。&&&&&&&&& 比如：p=&p.Name==1, p=&p.Name==1||p.Name==2&&&&&&&&& &&&&&&& 2:需要支持部分函数&&&&&&&&& 如果我们想做某个字段的模糊查询，在SQL中是用Like语句，在.net中我们可以调用StartWith,EndWith,Contains方法来完成&&&&&&&&& 比如:p=&p.Name.StartWith("1")&&&&&&&&& &&&&&&& 解决思路：&&&&&&& 表达式树一旦创建了它是不能修改其内容的，我们只能重新创建一个表达式树，所以我们的工作就是解析源表达式树，然后构造自己的表达式树，在构建过程后也就完成类型的转换。&&&&&&&&首先需要创建一个工具类用于转换：&&&&&&& TToB：指最终转换成的类型，我们这里就直接理解为数据库Model&&&&&&&&TR:就是表达式的返回值&&&&&&& TFrom:指源对象类型&&&&&&&&核心就是调用ConvertNode方法进入表达式的解析。&&&&&&& &public&class&ExpressionConverter&TToB&&&&&{&&&&&&&&public&static&Expression&Func&TToB,&TR&&&Convert&TFrom,&TR&(Expression&Func&TFrom,&TR&&&expr)&&&&&&&&{&&&&&&&&&&&&Dictionary&Expression,&Expression&&substitutues&=&new&Dictionary&Expression,&Expression&();&&&&&&&&&&&&var&oldParam&=&expr.Parameters[0];&&&&&&&&&&&&var&newParam&=&Expression.Parameter(typeof(TToB),&oldParam.Name);&&&&&&&&&&&&substitutues.Add(oldParam,&newParam);&&&&&&&&&&&&Expression&body&=&ConvertNode(expr.Body,&substitutues);&&&&&&&&&&&&return&Expression.Lambda&Func&TToB,&TR&&(body,&newParam);&&&&&&&&}}&&&&&&& 需求1的解决方案:&&&&&&&&&&&&对于普通的条件，无非就是一些二元操作，所以我们只要了解下ExpressionType的内容，然后根据不同的类型做不同的解析即可，比如处理二元表达式：下面文章中列表出各种ExpressionType的详细解释：&/zh-cn/library/bb361179(en-us,VS.90).aspx&&&View Code static&Expression&ConvertNode(Expression&node,&IDictionary&Expression,&Expression&&subst)&&&&&&&&{&&&&&&&&&&&&if&(node&==&null)&return&&&&&&&&&&&&&if&(subst.ContainsKey(node))&return&subst[node];&&&&&&&&&&&&switch&(node.NodeType)&&&&&&&&&&&&{&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&case&ExpressionType.Equal:&&&&&&&&&&&&&&&&&case&ExpressionType.And:&&&&&&&&&&&&&&&&case&ExpressionType.AndAlso:&&&&&&&&&&&&&&&&case&ExpressionType.LessThan:&&&&&&&&&&&&&&&&case&ExpressionType.NotEqual:&&&&&&&&&&&&&&&&case&ExpressionType.GreaterThan:&&&&&&&&&&&&&&&&//case&ExpressionType.:&&&&&&&&&&&&&&&&case&ExpressionType.Or:&&&&&&&&&&&&&&&&&&&&{&&&&&&&&&&&&&&&&&&&&&&&&var&be&=&(BinaryExpression)&&&&&&&&&&&&&&&&&&&&&&&&return&Expression.MakeBinary(be.NodeType,&ConvertNode(be.Left,&subst),&ConvertNode(be.Right,&subst),&be.IsLiftedToNull,&be.Method);&&&&&&&&&&&&&&&&&&&&}&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&default:&&&&&&&&&&&&&&&&&&&&throw&new&NotSupportedException(node.NodeType.ToString());&&&&&&&&&&&&}&&&&&&&&}&&&&&&&&&&&&&&& 需求2解决方案:&&&&&&&&&&&& 对于这部分有函数调用的地方，我们需要做特殊处理，目前只处理常用的Contains,StartWith,EndWith,其它的函数也可以继续做解析。&&&&&&&&View Code case&ExpressionType.Call:&&&&&&&&&&&&&&&&&&&&{&&&&&&&&&&&&&&&&&&&&&&&&var&be&=&(MethodCallExpression)&&&&&&&&&&&&&&&&&&&&&&&&var&expression&=&GetMethodExpression((MemberExpression)be.Object,&((ConstantExpression)be.Arguments[0]).Value.ToString(),&be.Method.Name,&subst);&&&&&&&&&&&&&&&&&&&&&&&&return&expression.B&&&&&&&&&&&&&&&&&&&&}&&&&&&&&&&&&&&&&static&Expression&Func&TToB,&bool&&&GetMethodExpression(&&&&&&&&&&&&MemberExpression&propertyExp,&&&&&&&&&&&&&&&&&&&&&&&&string&propertyValue,&&&&&&&&&&&&&string&MethodName,&&&&&&&&&&&&IDictionary&Expression,&Expression&&subst)&&&&&&&&{&&&&&&&&&&&&//var&parameterExp&=&Expression.Parameter(typeof(T),&((ParameterExpression)propertyExp.Expression).Name);&&&&&&&&&&&&var&newParameterExp&=&(ParameterExpression)ConvertNode((ParameterExpression)propertyExp.Expression,&subst);&&&&&&&&&&&&&&&&&&&&&&var&newPropertyExp&=&ConvertNode(propertyExp,&subst);&&&&&&&&&&&&MethodInfo&method&=&typeof(string).GetMethod(MethodName,&new[]&{&typeof(string)&});&&&&&&&&&&&&var&someValue&=&Expression.Constant(propertyValue,&typeof(string));&&&&&&&&&&&&var&containsMethodExp&=&Expression.Call(newPropertyExp,&method,&someValue);&&&&&&&&&&&&return&Expression.Lambda&Func&TToB,&bool&&(containsMethodExp,&newParameterExp);&&&&&&&&}&&&&&&&&&&&&&&& 补充：&&&&&&&&&&& 除了上面的二元表达式，方法调用表达式外，还有几个表达式也是重点：&&&&&&&&&& &1:ParameterExpression,即参数表达式，比如表达式p=&p.IsActive& 这里的{p}就是一个参数表达式&&&&&&&&&&&&2:ConstantExpression,即常量表达式，比如表达式p=&p.Name==1 这里的1就是常量表达式&&&&&&&&&&& 3:MemberExpression,即成员表达式，比如p.Name，这一步的操作我们能够实现业务数据Model与数据库Model之间的类型转换,它的原理就是比较成员是否一样，这里包括属性名称，属性类型等,有点类似反射，一个一个比，遇到相同的就赋值。&&&&&&&&&&&&&& 总结：&&&&&&&&&&&& 表达式树虽然看起来不太容易使用，但只要明白它的一些基本用法就能解决你的大部分问题，重点就是需要了解如何解析表达式树。&&&&&&& &&&&&&&&
、 、 、 、 、ADO.NET Entity Framework 在哪些场景下使用？
Enity Framework已经是.NET下最主要的ORM了。而ORM从一个Mapping的概念开始，到现在已经得到了一定的升华，特别是EF等对ORM框架面向对象能力的升华。切实地说，就是ORM让在整个应用过程中更好地被封装和抽象化。
ORM一开始只是Mapping，最基础的就是表与类的对应、Column和属性的对应，这只是最基础的。在这个层次上，数据库对象通过Mapping在面向对象语言层面，也就是业务层面被封装成了业务对象，然后允许以操作业务对象的方式对数据库进行操作。
但是，在很长时间里，ORM的提升都被对象与关系间的&阻抗失配&困扰。一直以来很多ORM的水平都只是维持在了用对象的方式进行CRUD而已，除了减少代码错误、提高简单查询的开发效率，在复杂查询、性能等等一些方面结果都还是要跨层回到底层的操作框架比如ADO.NET甚至存储过程去解决问题。
所以，在应用场景上来说简单查询的场景EF和其他ORM都是能够胜任的。
从应用场景说起，这点在B/S和C/S里也会很明显。用户使用Web的时候和使用桌面软件的最大体验不同是什么？&&所见即所得。你在网页上操作了半天，一个关闭就全没了，还必须提交然后获得下一个页面才能把数据状态和UI更新；而同样在桌面上，你的操作比如画图，在操作的一瞬间结果就出来了。当然了，Web 2.0技术就在解决这个问题。
同样在OO和RDBMS中的问题也在这里。
从OO的角度上看，你运行下一段代码结果如何：
user.Name = &Indream Luo&;
在OO里，就是user对象的Name属性被更新了。如果是一个桌面软件，那么用户的名称应该也更改了。
但是如果这个对象的数据是存在关系数据库中，或者任意数据库，那么结果都逃脱不出这个套路：
var object = db.Get(id);
change(ref object);
db.Update();
你需要把更新Push过去，将操作和数据持久化。
在存储分层开始，推送更新就不可避免，哪怕在说面应用中，也是将对象的更新推送到了UI。ORM站立在应用场景不一致中间所要扮演的角色，就是一个润滑剂的角色。
在我所能马上想起的特性，就是EF和NHibernate的缓存机制。EF是一级缓存，NH是二级缓存，手动的话似乎EF也可以做到二级。然后在.NET下最重要的一点是有LINQ。LINQ在有合适的Provider的情形下可以把OO的序列化操作转化成目标的序列化操作，在这里就是LINQ转SQL，这样就省去了拼接SQL、SQL注入等很多麻烦。另外LINQ延迟加载的特性也很大地减少了用户控制SQL执行的工作。
在操作同步的基础上，还有结构同步的问题。表结构和对象结构同步是使用ORM一大工作内容。EF有默认的生成工具，DB First、Model First、Code First三种模式提供选择，加上自动生成同步SQL，选择性是现在最广的，NH也有一些相应的生成器，数据库优先方面小弟LINQ to SQL的拖拽最惊艳。
在这个场景下，加上对相关工具的利用，EF等ORM适用于序列操作、减少数据库操作管理和结构同步工作量，减少开发成本。
最后，不可回避的就是阻抗失配的问题。
对象关系模型和关系数据库模型在以前很大程度上不一致，这是在以前。现在ORM要做的就是如何让两者更接近，让一边的特性能更顺滑地体现在另一边。
我 在早几个月写过一篇总结，关于最近一个项目EF使用的一些方法&&《Entity Framework 与 面向对象》。太长就选重点来说明。
EF所做的涵盖：类型匹配、对象结构、数据源区分。
类型匹配方面，就是把OO类型和数据库类型进行匹配，这是ORM的基础。基础类型中的整数、浮点、字符串、日期这些不在话下，EF比较有特点的可能是枚举类型（Enum）、复杂类型（Complex Type）、地理位置的功能，实现方式也比较理想。
对象结构方面是EF让我最惊艳的地方。EF的Model，也就是Entity能实现集成关系，也可以通过此同步在表结构中；EF中通过对外键的控制，对引用和依赖关系实现得十分出色；支持虚类、对象层面的Get/Set、访问控制都很好用。
插一段，通过使用Model First，我倒是发现数据库的设计更加接近于范式了。因为LINQ和对象结构方面带来的便利，我可以把表结构设计得更&合理&。比如如果要获取user的上司的上司，假设每个User都只有一个上司，那么用EF或者一些ORM就是：
var bigBoss = user.Superior.S
如果要写SQL，感觉有点烦，算代码量和可读性已经能看出区别了。
最后是数据源区分。有一个问题是一个对象，它的数据不一定完全源于数据库，或者一个数据库，这个例子我常用。
比如User有三个字段：FirstName、LastName、FullName。可以知道FullName其实就是FirstName和LastName的拼接，如果创建Model/Entity，一般：
public partial class User
& & public string FirstName { }
& & public string LastName { }
& & public string FullName
& & & & get
& & & & & & if (fullName == null)
& & & & & & {
& & & & & & & & this.fullName = String.Format(&{0} {1}&, this.FirstName, this.LastName);
& & & & & & }
& & & & & & return this.fullN
& & } string fullN
而在数据库里，只需要存储FirstName和LastName，FullName作为计算值就可以了，而且还是延迟加载的。
更甚者，我们还可以从上面的例子延伸，在Entity中封装一些数据库操作：
public partial class User
& & public User Superior { }
& & public User BigBoss
& & & & get
& & & & & & return this.Superior.S
此时在数据库中只存储一个Superior关系即可，BigBoss作为计算值就可以了。当然，你乐意还可以缓存和延迟加载，但EF已经处理了缓存了。
极端情况，确实是可以在表关系中&玩&不少面向对象的设计模式。
终上所述，EF适用于面向对象结构和特性优先性比较高的 场景。
那么相对地，也说说不适用的场景。
首先大家所诟病的是性能问题，这点希望不要抛开原理去说EF的性能。
EF由于其执行原理，性能损耗一般发生在：
LINQ也就是Expression Tree创建和转换成SQL的过程
缓存比对的过程
特殊操作实现不合理
极限性能压力下的问题
1是不可避免的，2通过关闭比对或者缓存可以解决，3、4和5是主要问题。
特殊操作不合理举例来说，比如递归，获取一个树结构的一条索引链。如果是通过OO来做，那么就是要么要往返很多次数据库，要么要至少遍历一次对象表，要么就是要加一些特殊的&丑陋的&索引字段。
极限性能压力在包含上个问题的情况下扩展，比如SQL Server的存储过程执行的特殊操作是最快的，纯OO的方式肯定达不到。
这两项特殊项通过更原生的数据库方式去解决是最佳的解决方案。你可以和EF混用，也可以单独使用，但不要妄想着有银弹能同时解决所有问题。EF提供了SQL的执行方式。
性能泄露不是一个专有名词，是我临时用的。意思是因为EF导致的不必要的性能浪费。特别是LINQ的延迟加载特性，许多不清楚LINQ特性的开发人员容易将LINQ序列无谓地实例化，浪费了资源。通常会是：
遍历查询全表数据， 然后再在OO层面进行筛选
无谓地执行实例化，进行查询，要么浪费缓存比对的资源，要么浪费查询资源
我只能说这是开发人员水平问题，虽然出现问题后很难定位，特别是一般情况下都会造成内存泄露。
最后最常见的还是回到数据模型同步的问题。当数据模型更改后，需要同步，这时候如果已经有业务数据了，是一件麻烦的事情。EF的Migration我没用过，是一个解决方案但似乎不那么完美。在一些非ORM应用的系统，SQL集中管理架构下，在这个场景，可能会更容易进行维护。
(window.slotbydup=window.slotbydup || []).push({
id: '2467140',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467141',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467143',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467148',
container: s,
size: '1000,90',
display: 'inlay-fix'ASP.Net中Ado.Net Entity Framework实际项目应用释疑_2016最新
WebjxCom提示：关于Ado.Net Entity Framework 的理论、入门教学文章已不少了，但是很少有人讲到在ASP.Net项目中实际项目应用的问题，往往学的时候轻松搞定，一上手项目就一头雾水。 关于Ado.Net Entity Framework 的理论、入门教学文章已不少了，但是很少
《ASP.Net中Ado.Net Entity Framework实际项目应用释疑_2016最新》摘自网络，版权归原作者
WebjxCom提示：关于Ado.Net Entity Framework 的理论、入门教学文章已不少了，但是很少有人讲到在ASP.Net项目中实际项目应用的问题，往往学的时候轻松搞定，一上手项目就一头雾水。
关于Ado.Net Entity Framework 的理论、入门教学文章已不少了，但是很少有人讲到在ASP.Net项目中实际项目应用的问题，往往学的时候轻松搞定，一上手项目就一头雾水。
比如在教程中最常见的这种形式的使用方法：
using(MyObjectContext c=new MyObjectContext())
如果在实际应用中，每每需要连接数据库，就造这么一个代码块的话，那么一个页面访问时就可能会创建数个数据库连接，致使并发用户访问数大打折扣；
而假如只使用一个这样的代码块的话，那么由于分层、服务器控件、用户控件等因素，又难以将所有数据库访问操作都揉到这一个代码块当中；
那么到底该怎样做才是最佳方案呢？
这个问题或许是Entity Framework的使用者产生疑惑最多的一点。
我在此将结合自己的经验，解答包括上述问题在内的一些在ASP.Net实际项目中容易产生的疑问。
首先，我们需要搭建一个演示环境。
建立一个数据库，并创建如下两个表：
关系：Article的PostUser字段对应到User的ID字段
将两个表分别填充一些数据：
生成Entity Framwork模型：
准备工作完成。
如何设计业务逻辑层？
如果要扩展实体类的功能，应该通过&部分类&(partial)实现：
如果需要借助ObjectContext对象查询或更新数据库，应将ObjectContext定义为方法参数，而不是在业务逻辑层中创建ObjectContext对象。
例如，下面的方法不应该出现在业务逻辑层：
更好的做法是：
上图中高亮的重载方法只应在需要时才编写，通常都可予以忽略。
(方法中的统计总数的代码语句完全可以由LinQ语句替代完成，并且非常精简，而这里只是象征性演示，别太在意)
如何快速通过主键获取对应实体？
这样是从缓存中直接取出实体对象，效率非常高。
如何优化查询性能？
可通过pile()预编译查询：
如何在同一页面中共享一个ObjectContext？
一般来说，一个页面只需要一个数据库连接，这样可以减少数据库的并发压力，使同一时间可以有更多用户访问网站。
而通常情况下，我们都使用ObjectContext的无参构造函数创建包含默认连接的ObjectContext对象，因此，在同一页面中共享一个ObjectContext就能实现同一页面共享一个数据库连接的目标。
接下来我们将在页面中放置两个EntityDataSource控件，分别获取所有用户及所有文章，并以ListView控件显示出来。
同时还要放置一个用户控件，用来获取并显示每个用户曾发布的文章。
我们先来创建用户控件界面：
用户控件界面中仅包含一个ListView控件。
（为了简单起见，ul中的li代码将由后台生成，然后直接绑定到这里）
接着是后台代码：
注意，这里定义了一个ObjectContext属性，程序将通过该属性访问数据库及业务逻辑层，但该属性并未在这里初始化，而是要由使用此用户控件的页面初始化该属性。
接下来编写页面前台代码：
简单的放置并配置了两个EntityDataSource及ListView，并放置了一个前面创建的用户控件。
后台代码：
这里也同样设置了一个ObjectContext属性，并在蓝色高亮处重写了OnInit，在其中进行初始化，并赋值给用户控件，然后在绿色高亮处重写了Dispose，对ObjectContext进行释放。
这样用户控件就将和页面使用同一个ObjectContext对象了。
然而，每个EntityDataSource还都会自己创建ObjectContext连接数据库，这显然不合我们的期望，解决办法是分别注册它们的ContextCreating、ContextDisposing事件，做如下处理：
这样页面虽然多次在不同的位置访问数据库，但仅使用一个ObjectContext、一个数据库连接。
执行结果：
如何在多个ObjectContext共享一个数据库连接？
EntityConnection即代表一个数据库连接，可以通过创建EntityConnection对象，并将其分配给多个ObjectContext对象，实现多ObjectContext共享单连接，具体方法可参看MSDN：
多ObjectContext共享一个连接，与整页面共享一个ObjectContext有什么不同呢？
《ASP.Net中Ado.Net Entity Framework实际项目应用释疑_2016最新》摘自网络，版权归原作者
(责任编辑：admin)
------分隔线----------------------------
让 Photoshop为您的照片添加美丽神奇的光芒 。按照此教程，了解如何能够非常容易地制...
<提示：大型的批发网站未必是门大生意。 几日前，我之前的同事来找我，希望对...
在充斥着css样式画廊和展示网站的世界里，什么网站看起来似乎都是一样的。 渐变，圆角...
WebjxCom提示：前几天遇到了一个问题，我在页面逻辑里需要调用一个webservice，处理一...
网页制作Webjx文章简介：工作分享:空行不空格式排版组织原理. 大量的多行段落本身就会...}