net模拟面试常见问题及复习资料.docx

1、 Response.Redirect(),Server.Transfer(),Server.Execute()的区别1、Response.Redirect():Response.Redirect方法导致浏览器链接到一个指定的URL。当Response.Redirect()方法被调用时，它会创建一个应答，应答头中指出了状态代码302（表示目标已经改变）以及新的目标URL。浏览器从服务器收到该应答，利用应答头中的信息发出一个对新URL的请求。这就是说，使用Response.Redirect方法时重定向操作发生在客户端，总共涉及到两次及服务器的通信（两个来回）：第一次是对原始页面的请求，得到一个302应答，第二次是请求302应答中声明的新页面，得到重定向之后的页面。Server.transfer是IIS 5.0新增加的一个功能。它解决了Response.Redirect的两个重要的缺陷：1）在Response.Redirect中，我们得不到任何第一页的输出2）Response.Redirect会丢失request中的所有属性，当然我们可以通过一些其他的办法，比如session来搞定，可是，有些页的参数是在request中传过来的，这样的话，就不行了；3) Response.Redirect需要client端再发起一个请求。server.transfer就很好地解决了这些问题。它是从server端直接向下一页发起请求，不需要client再次发送请求.如果你的网页非常依赖response.redirect,这个小小的改变可以提高将近25%的效率。（根据微软文档）.Server.Transfer方法把执行流程从当前的ASPX文件转到同一服务器上的另一个ASPX页面。调用Server.Transfer时，当前的ASPX页面终止执行，执行流程转入另一个ASPX页面，但新的ASPX页面仍使用前一ASPX页面创建的应答流。如果用Server.Transfer方法实现页面之间的导航，浏览器中的URL不会改变，因为重定向完全在服务器端进行，浏览器根本不知道服务器已经执行了一次页面变换。默认情况下，Server.Transfer方法不会把表单数据或查询字符串从一个页面传递到另一个页面，但只要把该方法的第二个参数设置成True，就可以保留第一个页面的表单数据与查询字符串。 同时，使用Server.Transfer时应注意一点：目标页面将使用原始页面创建的应答流，这导致ASP.NET的机器验证检查（MachineAuthentication Check，MAC）认为新页面的ViewState已被篡改。因此，如果要保留原始页面的表单数据与查询字符串集合，必须把目标页面Page指令的 EnableViewStateMac属性设置成False。server.Transfer()有一个不足就是:当用户在a.aspx中提交了一个表单,然后用Server.Transfer()进入 b.aspx，这时如果用户刷新一下页面，浏览器便会问用户是否“重试”发送表单，如果用户点击“是”，那么，表单中的数据被重新发送到服务器。如发送表单的作用就是为了向数据库中插入一条记录，结果导不希望发生的事同一表单被多次加入到数据库中。Server.Execute方法允许当前的ASPX页面执行一个同一Web服务器上的指定ASPX页面，当指定的ASPX页面执行完毕，控制流程重新返回原页面发出Server.Execute调用的位置。这种页面导航方式类似于针对ASPX页面的一次函数调用，被调用的页面能够访问发出调用页面的表单数据与查询字符串集合，所以要把被调用页面Page指令的EnableViewStateMac属性设置成False。4.erver.Execute("another.aspx")与Server.Transfer("another.aspx")区别: Execute是从当前页面转移到指定页面,并将执行返回到当前页面 Transfer是将执行完全转移到指定页面 总结：在网络状态较好的情况下,Redirect(url)方法效率最高! 可重定向到同一台或非同一台服务器上的aspx或非aspx（html）资源Server.Transfer方法与Server.Execute方法最灵活! 但只能转到同一Application目录下，也有可能导致不期望的结果发生Server.Execute方法占用资源最多. 2、 SQL 2005 的新特性是什么 ？ 及oracle 有什么区别？一、数据库设计方面1、字段类型。varchar(max)nvarchar(max)类型的引入大大的提高了编程的效率，可以使用字符串函数对CLOB类型进行操作，这是一个亮点。但是这就引发了对varchar与char效率讨论的老问题。到底如何分配varchar的数据，是否会出现大规模的碎片？是否碎片会引发效率问题？这都是需要进一步探讨的东西。varbinary(max)代替image也让SQL Server的字段类型更加简洁统一。XML字段类型更好的解决了XML数据的操作。XQuery确实不错，但是个人对其没好感。（CSDN的开发者应该是相当的熟了！）2、外键的级联更能扩展可能大部分的同行在设计OLTP系统的时候都不愿意建立外键，都是通过程序来控制父子数据的完整性。但是再开发调试阶段与OLAP环境中，外键是可以建立的。新版本中加入了SET NULL 与 SET DEFAULT 属性，能够提供能好的级联设置。3、索引附加字段这是一个不错的新特性。虽然索引的附加字段没有索引键值效率高，但是相对映射到数据表中效率还是提高了很多。我做过试验，在我的实验环境中会比映射到表中提高30%左右的效率。4、计算字段的持久化原来的计算字段其实与虚拟字段很像。只是管理方面好了而已，性能方面提高不多。但是SQL2005提供了计算字段的持久化，这就提高了查询的性能，但是会加重insert与update的负担。OLTP慎用。OLAP可以大规模使用。5、分区表分区表是个亮点！从分区表也能看出微软要做大作强SQL Server的信心。资料很多，这里不详细说。但是重点了解的是：现在的SQL Server2005的表，都是默认为分区表的。因为它要支持滑动窗口的这个特性。这种特性对历史数据与实时数据的处理是很有帮助的。但是需要注意的一点，也是我使用过程中发现的一个问题。在建立function->schema->table后，如果在现有的分区表上建立没有显式声明的聚集索引时，分区表会自动变为非分区表。这一点很让我纳闷。如果你觉得我的非分区索引无法对起子分区，你可以提醒我一下呀！没有任何的提醒，直接就变成了非分区表。不知道这算不算一个bug。大家也可以试试。分区表效率问题肯定是大家关心的问题。在我的试验中，如果按照分区字段进行的查询（过滤）效率会高于未分区表的相同语句。但是如果按照非分区字段进行查询，效率会低于未分区表的相同语句。但是随着数据量的增大，这种成本差距会逐渐减小，趋于相等。（500万数量级只相差10%左右）6、CLR类型微软对CLR作了大篇幅的宣传，这是因为数据库产品终于融入.net体系中。最开始我们也是狂喜，感觉对象数据库的一些概念可以实现了。但是作了些试验，发现使用CLR的存储过程或函数在达到一定的阀值的时候，系统性能会呈指数级下滑！这是非常危险的！只使用几个可能没有问题，当一旦大规模使用会造成严重的系统性能问题！其实可以做一下类比，Oracle等数据库产品老早就支持了java编程，而且提供了java池参数作为用户配置接口。但是现在有哪些系统大批使用了java存储过程？！连Oracle自己的应用都不用为什么？！还不是性能有问题！否则面向对象的数据库早就实现了！建议使用CLR的地方一般是与应用的复杂程度或操作系统环境有很高的耦合度的场景。如你想构建复杂的算法，并且用到了大量的指针与高级数据模型。或者是要与操作系统进行Socket通讯的场景。否则建议慎重！7、索引视图索引视图2k就有。但是2005对其效率作了一些改进但是schema.viewname的作用域真是太限制了它的应用面。还有一大堆的环境参数与种种限制都让人对它有点却步。8、语句与事务快照语句级快照与事务级快照终于为SQL Server的并发性能带来了突破。个人感觉语句级快照大家应该应用。事务级快照，如果是高并发系统还要慎用。如果一个用户总是被提示修改不成功要求重试时，会杀人的！9、数据库快照原理很简单，对要求长时间计算某一时间点的报表生成与防用户操作错误很有帮助。但是比起Oracle10g的闪回技术还是细粒度不够。可惜！二、开发方面1、Ranking函数集其中最有名的应该是row_number了。这个终于解决了用临时表生成序列号的历史，而且SQL Server2005的row_number比Oracle的更先进。因为它把Order by集成到了一起，不用像Oracle那样还要用子查询进行封装。但是大家注意一点。如下面的例子：select ROW_NUMBER() OVER (order by aa)from tblorder by bb会先执行aa的排序，然后再进行bb的排序。可能有的朋友会抱怨集成的order by，其实如果使用ranking函数,Order by是少不了的。如果担心Order by会影响效率，可以为order by的字段建立聚集索引，查询计划会忽略order by 操作（因为本来就是排序的嘛）。2、top可以动态传入参数，省却了动态SQL的拼写。3、Apply对递归类的树遍历很有帮助。4、CTE个人感觉这个真是太棒了！阅读清晰，非常有时代感。5、try/catch代替了原来VB式的错误判断。比Oracle高级不少。6、pivot/unpivot个人感觉没有case直观。而且默认的第三字段（还可能更多）作为group by字段很容易造成新手的错误。三、DBA管理方面1、数据库级触发器记得在最开始使用2k的时候就要用到这个功能，可惜2k没有，现在有了作解决方案的朋友会很高兴吧。2、多加的系统视图与实时系统信息这些东西对DBA挑优非常有帮助，但是感觉粒度还是不太细。3、优化器的改进一直以来个人感觉SQL Server的优化器要比Oracle的聪明。SQL2005的更是比2k聪明了不少。（有次作试验发现有的语句在200万级时还比50万级的相同语句要快show_text的一些提示没有找到解释。一直在奇怪。）4、profiler的新事件观察这一点很好的加强了profiler的功能。但是提到profiler提醒大家注意一点。windows2003要安装sp1补丁才能启动profiler。否则点击没有反应。5、sqlcmd习惯敲命令行的朋友可能会爽一些。但是功能有限。适合机器跑不动SQL Server Management Studio的朋友使用。3、 ASP.NET MVC介绍 MVC把一个web应用分成了三个部分：model view与controller。ASP.NET MVC框架提供了一个可以代替 web窗体的基于mvc的应用。 ASP.NET MVC概述·mvc的优点： 1.通过把项目分成model view与controller，使得复杂项目更加容易维护。 2.没有使用view state与服务器表单控件，可以更方便的控制应用程序的行为 3.应用程序通过controller来控制程序请求，可以提供丰富的url重写。 4.对单元测试的支持更加出色 5.在团队开发模式下表现更出众 ASP.NET MVC概述·web窗体的优点： 1.采用事件驱动模式来控制应用程序请求，由大量服务器控件支持 2.采用页面控制机制，可以为单个页面添加事件处理函数。 3.使用view state与服务器端页面，使管理页面状态信息更加轻松。 4.对人数较少的想使用服务器端控件的开发团队，使用起来更加方便 5.开发起来比mvc模式要轻松简单一些 ASP.NET MVC概述mvc框架特色： 1.分离任务（输入逻辑，业务逻辑与显示逻辑），易测性与默认的测试驱动组件。所有mvc用到的组件都是基于接口并且可以被mock对象测试到，你可以不必在进程中运行controller就可以使用测试。使得测试更加快速与简捷。 2.可扩展的简便的框架。mvc框架被设计用来更轻松的移植与定制功能。你可以加入自己的视图引擎，url重写策略。重载action方法等。mvc也支持Dependency Injection (DI) and Inversion of Control (IOC） 3.强大的url重写机制让你更方便的建立容易理解与可搜索的url。url可以不包含任何文件扩展名，并且可以重写url使其对搜索引擎更加友好。 4.可以使用现有的页面标记、用户控件、模板页。你可以使用嵌套模板页，嵌入表达式<%=%>,声明服务器控件、模板，数据绑定、定位等等。 5.对现有的程序的支持，mvc让你可以使用如窗体认证与windows认证、url认证、组管理与规则、输出、数据缓存、session、profile 、health monitoring、配置管理系统、provider architecture特性。4、 SQL Server 三种复制的区别1、事务复制 将复制启用后的所有发布服务器上发布的内容在修改时传给订阅服务器； 数据更改将按照其在发布服务器上发生的顺序与事务边界，应用于订阅服务器； 在发布内部可以保证事务的一致性； 2、快照复制 将数据以特定时刻的瞬时状态分发，而不监视对数据的更新； 发生同步时，将生成完整的快照，并将其发送到订阅服务器；3、合并复制 通常从发布数据库对象与数据的快照开始，并且用触发器跟踪在发布器与订阅服务器上所做的后续更改与架构修改； 订阅服务器在连接到网络时将及发布服务器进行同步，并交换自上次同步以来发布服务器与订阅服务器之间发生更改的所有行；5、 请你谈一谈你对值类型及引用类型的理解？1. 所有对象都继承自System.Object，而所有的值类型都继承自System.ValueType。也就是说，System.ValueType重写了System.Object的方法使得值类型的操作是基于值而不是基于引用。2. 值类型内存分配在栈上，引用类型内存分配在托管堆中。内存分配在这两个地方的区别在于：如果超出了值类型定义的范围，值类型分配的内存会立刻从内存中清除，即它的内存生命周期是可以预测的。而引用类型分配在托管堆中，内存管理有垃圾处理器控制，不可预知其生命周期。3. 赋值操作值类型赋值操作是会依次copy所有成员变量的值。引用类型仅仅是地址重定向。4. 参数传递默认为值传递，即参数为值类型是传递值类型的值副本，参数为引用类型时传递引用类型地址值副本。但当参数使用out或者ref关键字是，传递的是引用本身。但是在使用ref，需要注意一些区别：当参数为引用类型时，不使用ref关键字，方法还是可以通过传入的引用改变其所指向的实例，但是不能改变引用本身。 当参数为引用类型时，同时使用ref关键字，方法可以通过传入的引用改变其所指向的实例，并且改变引用本身。 5. 值类型是sealed的，不能继承6. 值类型不能写Finalize()方法，该方法用于堆上的内存回收。7. 装箱及拆箱装箱 - 把值类型转换为引用类型。拆箱 - 把引用类型转换为值类型。作用：可以把值类型也看作是对象。最常使用的情况是在集合操作的时候，大多数方法接口都接收一个对象参数（object）。当传入值类型时，.NET会自动处理装箱细节，把值类型转变为引用类型。从集合取出时，把引用类型的值取出放回值类型变量。缺点：性能上有损失。并且缺少类型安全保证。.NET 2.0推出了泛型 基本上能解决这个问题。6、private、protected、public与internal的区别?private是完全私有的，只有在类自己里面可以调用，在类的外部与子类都不能调用，子类也不能继承父类的private的属性与方法。protected虽然可以被外界看到，但外界却不能调用，只有自己及自己的子类可以调用（protected的属性与方法都可以被子类所继承与调用）。private与protected的共同点：外部都不可以访问。private与protected的不同点：在同一类中可视为一样，但在继承中就不同了，private在派生类中不可以被访问，而protected可以。public对任何类与成员都完全公开，无限制访问。internal同一应用程序集内部（在VS.NET中的一个项目中，这里的项目是指单独的项目，而不是整个解决方案）可以访问。public与internal的区别：public的成员可以跨程序集，但internal不能，同一程序集中具有相同的效果。protected internal：只能在同一应用程序集内本类、派生类访问。7、 ASP.NET如何进行性能优化问题？我们将从5方面来进行ASP.NET性能优化：一、SqlDataRead与Dataset的选择Sqldataread优点：读取数据非常快。如果对返回的数据不需做大量处理的情况下，建议使用SqlDataReader，其性能要比datset好很多。缺点：直到数据读完才可close掉于数据库的连接(SqlDataReader 读数据是快速向前的。SqlDataReader 类提供了一种读取从 SQL Server 数据库检索的只进数据流的方法。它使用 SQL Server 的本机网络数据传输格式从数据库连接直接读取数据。DataReader需及时显式的close。可及时的释放对数据的连接。)Dataset是把数据读出，缓存在内存中。缺点：对内存的占用较高。如果对返回的数据需做大量的处理用Dataset比较好些可以减少对数据库的连接操作。优点：只需连接一次就可close于数据库的连接一般情况下,读取大量数据,对返回数据不做大量处理用SqlDataReader.对返回数据大量处理用datset比较合适.对SqlDataReader与Dataset的选择取决于程序功能的实现。二、ExecuteNonQuery与ExecuteScalar对数据的更新不需要返回结果集，建议使用ExecuteNonQuery。由于不返回结果集可省掉网络数据传输。它仅仅返回受影响的行数。如果只需更新数据用ExecuteNonQuery性能的开销比较小。ExecuteScalar它只返回结果集中第一行的第一列。使用 ExecuteScalar 方法从数据库中检索单个值（例如id号）。及使用 ExecuteReader 方法， 返回的数据执行生成单个值所需的操作相比，此操作需要的代码较少。只需更新数据用ExecuteNonQuery.单个值的查询使用ExecuteScalar数据绑定的选择三、数据的绑定DataBinder一般的绑定方法<%# DataBinder.Eval(Container.DataItem, "字段名") %>用DataBinder.eval 绑定不必关心数据来源(Dataread或dataset)。不必关心数据的类型eval会把这个数据对象转换为一个字符串。在底层绑定做了很多工作，使用了反射性能。正因为使用方便了，但却影响了数据性能。来看下<%# DataBinder.Eval(Container.DataItem, "字段名") %>。当于dataset绑定时，DataItem其实式一个DataRowView（如果绑定的是一个数据读取器（dataread）它就是一个IdataRecord。）因此直接转换成DataRowView的话，将会给性能带来很大提升。<%# ctype(Container.DataItem,DataRowView).Row("字段名") %>对数据的绑定建议使用<%# ctype(Container.DataItem,DataRowView).Row("字段名") %>。数据量大的时候可提高几百倍的速度。使用时注意2方面：1.需在页面添加<% Import namespace="System.Data"%>.2.注意字段名的大小写（要特别注意）。如果与查询的不一致，在某些情况下会导致比<%# DataBinder.Eval(Container.DataItem, "字段名") %>还要慢。如果想进一步提高速度，可采用<%# ctype(Container.DataItem,DataRowView).Row(0) %>的方法。不过其可读性不高。以上的是的写法。在c#中：<% (DataRowView)Container.DataItem)"字段名" %> 对查看页面每个执行过程状态最简单的办法：其页面的trace属性为true就可查看细节。一、使用存储过程： 1、性能方面：存储过程提供了许多标准sql语言中所没有的高级特性。其传递参数与执行逻辑表达式的功能，有助于应用程序设计者处理复杂任务。另外，存储过程存储在本地服务器上，减少了执行该过程所需的网络传输宽带与执行时间。（存储过程已经对sql语句进行了预编译，所以其执行速度比在程序里执行sql语句快很多） 2、程序结构方面：从程序的可扩展性看，使用存储过程会对程序以后的修改带来方便。比如数据库的结构改变了，只需修改相对应的存储结构，与程序中的调用部分即可。这部分不属于本文探讨范围，属于程序结构设计方面。所以不在此展开。 3、程序安全性：使用存储过程可避免SQL Injection攻击。 二、查询语句的优化（针对sql server2000） 很多人只为目的写出sql语句，而不考虑sql语句的执行效率。在这我只提供一优化表顺序的方法，（sql语句的优化与原则将会在我的sql server2000学习笔记中专题讨论） 对sql语句执行效率可用sql server2000的查询分析器来查看语句的执行过程。 优化表顺序：一般情况下，sqlserver 会对表的连接作出自动优化。例如：select name,no from A join B on A. id=B.id join C on C.id=A.id where name=wang 尽管A表在From中先列出，然后才是B,最后才是C。但sql server可能会首先使用c表。它的选择原则是相对于该查询限制为单行或少数几行，就可以减少在其他表中查找的总数据量。绝大多数情况下，sql server 会作出最优的选择，但如果你发觉某个复杂的联结查询速度比预计的要慢，就可以使用SET FORCEPLAN语句强制sql server按照表出现顺序使用表。如上例加上：SET FORCEPLAN ON.SET FORCEPLAN OFF 表的执行顺序将会按照你所写的顺序执行。在查询分析器中查看2种执行效率，从而选择表的连接顺序。 使用SET FORCEPLAN选择表联结顺序 三、页面的优化（.aspx） 主要针对几个页面属性 1、EnableViewState(页面的视图状态)。如果无特殊要求设置为false。使用ViewState ，每个对象都必须先序列化到 ViewState 中，然后再通过回传进行反序列化，因此使用 ViewState是没有代价的。尽量减少使用对象，如果可能，尽量减少放入 ViewState 中的对象的数目。下面情况基本上可以禁用viewstate： （1）页面控件 （.ascx） （2）页面不回传给自身。 （3）无需对控件的事件处理。 （4）控件没有动态的或数据绑定的属性值（或对于每个postpack都在代码中处理） 单个页面或每个页面都禁用 ViewState，如下所示：单个页面：<% Page EnableViewState="False" %> 每个页面：在 web.config 中 <Pages EnableViewState="false" /> EnableSessionState保持默认值即可（如果页面用到sessionstate它才会占用资源）。EnableViewStateMac如果无安全上的特殊要求，保持默认值。 2、Pagelayout.页面布局模型。建议使用Flowlayout(元素不带绝对定位属性添加).Gridlayout(绝对定位属性)由于采用绝对定位，将会比Flowlayout生产更多的代码，主要是控件的定位信息。 3、项目发布的时候切记解除页面的Debug状态。 4、Html语言的优化。我的建议是熟练掌握Html/javascript，少用2003自动生产的代码，它会自动生成一些无用的html代码。 5、smart navigation设置为true能让用户明显的感觉性能提高。启用此属性后对客户端与服务端影响不大.它能智能涮新需要涮新需涮新的部分.四、控件的选择： Html控件与服务器控件的选择。服务器控件带来的方便与功能上的实现是html控件所不能比拟的。但是是以牺牲服务器端的资源来取得的。我个人建议：如果html控件达不到所要实现的功能，而且与一些脚本语言（如javascrpt/vbscript）结合也不能实现的话。才会选择服务器控件。选择服务器控件后，也尽量对其控件优化，如取消一些页面状态等（具体看控件的优化） 服务器控件的选择：主要针对几个常用数据控件说明一下： DataGrid：自带最强大的数据显示控件，内置了对数据的修改、删除、添加、分页等很多实用功能。如果你只需对数据显示的话，尽量不要选择DataGrid（它把数据都存储在viewstate中）.也不要使用自带的分页功能，microsoft在自动分页的底层做了很多工作，虽然使用方便了，但性能开销大了。DataList：比DataGrid功能少了很多。但自定义性强了很多。特有的多行数据显示，给我们带来了很多方便。DataGrid能实现的功能，它基本能实现。所以建议使用它。 Repeater：功能最少，但自定义性非常强。如果只需对数据显示，建议使用。由于减少了很多功能，对服务器的性能带来消耗最小。因此，如果是对数据显示的话，我基本上都是选择Repeater然后DataList最后DataGrid 尽量选择html控件。能在客户端实现的功能就在客户端实现(熟练掌握javascript)，减少服务器的压力。数据控件选择顺序：Repeater、DataList、DataGrid 五、服务器控件的优化： 1、Viewstate 控件的viewstate及页面的viewstate基本是一致的。用来保存控件的一些状态。处理原则与处理页面的viewstate一样。有兴趣的可以用Datagrid绑定数据测试下viewstate保存的数据量有多大，它所保存的数据基本与Datagrid显示的数据量大小是等同的。 2、Ispostpack 默认false.需要产生事件的时候才需设置为true. 控件的优化，主要看你对此控件的熟悉情况。对控件内部运作的原理越了解，就会对其作出合适的优化。 性能优化是三两句话说不清的，我所写出的仅仅是冰山一角，性能的优化是靠平时经验的积累与对程序的运作原理的不断认知。