几个比较容易混淆的问题
1 foreach 和 for 的效率那个更高
这要看 所遍历的集合采用的数据结构,如果是顺序存储(比如数组),则for更快,如果采用链式存储,则采用foreach的效率更高
2 C# 访问修饰符的类型
五种而不是四种,不写任何修饰符的时候是private,而在java里面是package(不同于internal,internal表示同一个程序集,即使是两个名字空间)。
public>>internal protected>>internal<>protected>>private 共有五种
值得注意的是 internal protected 修饰符,表示可以在程序集内访问,也可以在派生类中访问。
3 ViewState和Session 那个更消耗服务器资源
通常情况下, Session 更消耗服务器内存资源,而ViewState因为涉及到编码和解码,所以比较消耗处理器资源;另外,在集群环境下,需要考虑Session的同步和复制带来的开销;如果Session保存于非Web进程,则需要考虑跨进程调用的开销;如果Session保存于数据库中,则要考虑数据访问的开销。
4 WebService vs Remoting
ASP.NET Web 服务基础结构通过将 SOAP 消息映射到方法调用,为 Web 服务提供了简单的 API。通过提供一种非常简单的编程模型(基于将 SOAP 消息交换映射到方法调用),它实现了此机制。ASP.NET Web 服务的客户端不需要了解用于创建它们的平台、对象模型或编程语言。而服务也不需要了解向它们发送消息的客户端。唯一的要求是:双方都要认可正在创建和使用的 SOAP 消息的格式,该格式是由使用 WSDL 和 XML 架构 (XSD) 表示的 Web 服务合约定义来定义的。
. NET Remoting 为分布式对象提供了一个基础结构。它使用既灵活又可扩展的管线向远程进程提供 .NET 的完全对象语义。ASP.NET Web 服务基于消息传递提供非常简单的编程模型,而 .NET Remoting 提供较为复杂的功能,包括支持通过值或引用传递对象、回调,以及多对象激活和生命周期管理策略等。要使用 .NET Remoting,客户端需要了解所有这些详细信息,简而言之,需要使用 .NET 建立客户端。.NET Remoting 管线还支持 SOAP 消息,但必须注意这并没有改变其对客户端的要求。如果 Remoting 端点提供 .NET 专用的对象语义,不管是否通过 SOAP,客户端必须理解它们。
5 WebService相关技术
SOAP:(Simple Object Access Protocol )简单对象访问协议是在分散或分布式的环境中交换信息的简单的协议,是一个基于XML的协议,它包括四个部分:SOAP封装(envelop),封装定义了一个描述消息中的内容是什么,是谁发送的,谁应当接受并处理它以及如何处理它们的框架;SOAP编码规则(encoding rules),用于表示应用程序需要使用的数据类型的实例; SOAP RPC表示(RPC representation),表示远程过程调用和应答的协定;SOAP绑定(binding),使用底层协议交换信息。
WSDL:WSDL(Web Service Description Language)Web服务器描述语言是用XML文档来描述Web服务的标准,是Web服务的接口定义语言,由Ariba、Intel、IBM、MS等共同提出,通过WSDL,可描述Web服务的三个基本属性:
•服务做些什么——服务所提供的操作(方法)
•如何访问服务——和服务交互的数据格式以及必要协议
•服务位于何处——协议相关的地址,如URL
UDDI:(Universal Description, Discovery and Integration)统一描述、发现和集成协议,是为解决Web服务的发布和发现问题而制订的新一代基于Internet的电子商务技术标准。它包含一组基于Web的、分布式的Web服务信息注册中心的实现标准,以及一组使企业能将自己提供的Web服务注册到该中心的实现标准。UDDI利用SOAP消息来查找和注册Web服务。并为应用程序提供了一系列接口来访问注册中心。关于UDDI的详细内容可参考:http://www.uddi.org/
这三种技术互相都有联系,比如说 UDDI服务就是通过SOAP消息去发现Web服务。他们共同解决了 WebService 的发现、描述、访问的问题
6 override overload polymorphism(重写、重载、多态)
Override没有问题,关键是overload到底是否多态的一种实现方法?有人认为多态一定是迟绑定的,而overload并非迟绑定的,所以 overload跟多态没有关系;还有人说,多态的实现分override和overload两种形式,一种是类层次的,一种是方法层次的,或者说一种编译时多态,一种运行时多态;当然,也有人认为,overload根本不是面向对象独有的特性,在面向过程的语言中也同样存在。总之,对于这个问题,我比较倾向overload非多态实现的这种说法。
这要看 所遍历的集合采用的数据结构,如果是顺序存储(比如数组),则for更快,如果采用链式存储,则采用foreach的效率更高
2 C# 访问修饰符的类型
五种而不是四种,不写任何修饰符的时候是private,而在java里面是package(不同于internal,internal表示同一个程序集,即使是两个名字空间)。
public>>internal protected>>internal<>protected>>private 共有五种
值得注意的是 internal protected 修饰符,表示可以在程序集内访问,也可以在派生类中访问。
3 ViewState和Session 那个更消耗服务器资源
通常情况下, Session 更消耗服务器内存资源,而ViewState因为涉及到编码和解码,所以比较消耗处理器资源;另外,在集群环境下,需要考虑Session的同步和复制带来的开销;如果Session保存于非Web进程,则需要考虑跨进程调用的开销;如果Session保存于数据库中,则要考虑数据访问的开销。
4 WebService vs Remoting
ASP.NET Web 服务基础结构通过将 SOAP 消息映射到方法调用,为 Web 服务提供了简单的 API。通过提供一种非常简单的编程模型(基于将 SOAP 消息交换映射到方法调用),它实现了此机制。ASP.NET Web 服务的客户端不需要了解用于创建它们的平台、对象模型或编程语言。而服务也不需要了解向它们发送消息的客户端。唯一的要求是:双方都要认可正在创建和使用的 SOAP 消息的格式,该格式是由使用 WSDL 和 XML 架构 (XSD) 表示的 Web 服务合约定义来定义的。
. NET Remoting 为分布式对象提供了一个基础结构。它使用既灵活又可扩展的管线向远程进程提供 .NET 的完全对象语义。ASP.NET Web 服务基于消息传递提供非常简单的编程模型,而 .NET Remoting 提供较为复杂的功能,包括支持通过值或引用传递对象、回调,以及多对象激活和生命周期管理策略等。要使用 .NET Remoting,客户端需要了解所有这些详细信息,简而言之,需要使用 .NET 建立客户端。.NET Remoting 管线还支持 SOAP 消息,但必须注意这并没有改变其对客户端的要求。如果 Remoting 端点提供 .NET 专用的对象语义,不管是否通过 SOAP,客户端必须理解它们。
5 WebService相关技术
SOAP:(Simple Object Access Protocol )简单对象访问协议是在分散或分布式的环境中交换信息的简单的协议,是一个基于XML的协议,它包括四个部分:SOAP封装(envelop),封装定义了一个描述消息中的内容是什么,是谁发送的,谁应当接受并处理它以及如何处理它们的框架;SOAP编码规则(encoding rules),用于表示应用程序需要使用的数据类型的实例; SOAP RPC表示(RPC representation),表示远程过程调用和应答的协定;SOAP绑定(binding),使用底层协议交换信息。
WSDL:WSDL(Web Service Description Language)Web服务器描述语言是用XML文档来描述Web服务的标准,是Web服务的接口定义语言,由Ariba、Intel、IBM、MS等共同提出,通过WSDL,可描述Web服务的三个基本属性:
•服务做些什么——服务所提供的操作(方法)
•如何访问服务——和服务交互的数据格式以及必要协议
•服务位于何处——协议相关的地址,如URL
UDDI:(Universal Description, Discovery and Integration)统一描述、发现和集成协议,是为解决Web服务的发布和发现问题而制订的新一代基于Internet的电子商务技术标准。它包含一组基于Web的、分布式的Web服务信息注册中心的实现标准,以及一组使企业能将自己提供的Web服务注册到该中心的实现标准。UDDI利用SOAP消息来查找和注册Web服务。并为应用程序提供了一系列接口来访问注册中心。关于UDDI的详细内容可参考:http://www.uddi.org/
这三种技术互相都有联系,比如说 UDDI服务就是通过SOAP消息去发现Web服务。他们共同解决了 WebService 的发现、描述、访问的问题
6 override overload polymorphism(重写、重载、多态)
Override没有问题,关键是overload到底是否多态的一种实现方法?有人认为多态一定是迟绑定的,而overload并非迟绑定的,所以 overload跟多态没有关系;还有人说,多态的实现分override和overload两种形式,一种是类层次的,一种是方法层次的,或者说一种编译时多态,一种运行时多态;当然,也有人认为,overload根本不是面向对象独有的特性,在面向过程的语言中也同样存在。总之,对于这个问题,我比较倾向overload非多态实现的这种说法。