.net模拟面试常见问题及答案

1、Response.Redirect(),Server.Transfer(),Server.Execute()的区别
1、Response.Redirect():
Response.Redirect方法导致浏览器链接到一个指定的URL。

当Response.Redirect()方法被调用时，它会创建一个应答，应答头中指出了状态代码302（表示目标已经改变）以及新的目标URL。

浏览器从服务器收到该应答，利用应答头中的信息发出一个对新URL的请求。

这就是说，使用Response.Redirect方法时重定向操作发生在客户端，总共涉及到两次与服务器的通信（两个来回）：第一次是对原始页面的请求，得到一个302应答，第二次是请求302应答中声明的新页面，得到重定向之后的页面。

2、Server.Transfer
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时应注意一点：目标页面将使用原始页面创建的应答流，这导致的机器验证检查（Machine
Authentication Check，MAC）认为新页面的ViewState已被篡改。

因此，如果要保留原始页面的表单数据和查询字符串集合，必须把目标页面
Page指令的EnableViewStateMac属性设置成False。

server.Transfer()有一个不足就是:当用户在 a.aspx中提交了一个表单,然后用Server.Transfer()进入b.aspx，这时如果用户刷新一下页面，
浏览器便会问用户是否“重试”发送表单，如果用户点击“是”，那么，表单中的数据被重新发送到服务器。

如发送表单的作用就是为了向数
据库中插入一条记录，结果导不希望发生的事——同一表单被多次加入到数据库中。

3、Server.Execute
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 tbl
order 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、A MVC介绍
MVC把一个web应用分成了三个部分：model view和controller。

MVC框架提供了一个可以代替 web窗体的基于mvc的应用。

MVC概述·mvc的优点：
1.通过把项目分成model view和controller，使得复杂项目更加容易维护。

2.没有使用view state和服务器表单控件，可以更方便的控制应用程序的行为
3.应用程序通过controller来控制程序请求，可以提供丰富的url重写。

4.对单元测试的支持更加出色
5.在团队开发模式下表现更出众
MVC概述·web窗体的优点：
1.采用事件驱动模式来控制应用程序请求，由大量服务器控件支持
2.采用页面控制机制，可以为单个页面添加事件处理函数。

3.使用view state和服务器端页面，使管理页面状态信息更加轻松。

4.对人数较少的想使用服务器端控件的开发团队，使用起来更加方便
5.开发起来比mvc模式要轻松简单一些
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同一应用程序集内部（在中的一个项目中，这里的项目是指单独的项目，而不是整个解决方案）可以访问。

public和internal的区别：public的成员可以跨程序集，但internal不能，同一程序集中具有相同的效果。

protected internal：只能在同一应用程序集内本类、派生类访问。

7、如何进行性能优化问题？
我们将从5方面来进行性能优化：
一、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.
控件的优化，主要看你对此控件的熟悉情况。

对控件内部运作的原理越了解，就会对其作出合适的优化。

性能优化是三两句话说不清的，我所写出的仅仅是冰山一角，性能的优化是靠平时经验的积累和对程序的运作原理的不断认知。