.NET发表评论(0)编辑词条

.net

.NET是Microsoft XML Webservices平台。XML Webservices允许应用程序通过Internet进行通讯和共享数据，而不管所采用的是哪种操作系统、设备或编程语言。Microsoft.NET平台提供创建XMLWebservices并将这些服务集成在一起之所需。

[显示部分][显示全部]

基本概述编辑本段 回目录

.net

WebServices是.NET的核心技术。Web是新一代的用户与应用交互的途径，XML是新一代的程序之间通讯的途径一样，Web Services是新一代的计算机与计算机之间一种通用的数据传输格式，可让不同运算系统更容易进行数据交换。Web Services有以下几点特性：Webservices允许应用之间共享数据；Web services分散了代码单元；基于XML这种internet数据交换的通用语言，实现了跨平台、跨操作系统、跨语言。那微软的ASP和Webservices究竟有什么不同呢，ASP仍然是一个集中式计算模型的产物，只不过是披着一层互联网的外衣。但WebServices却是一个迥然不同的精灵，它秉承“软件就是服务”的真言，同时顺应分布式计算模式的潮流。而它的存在形式又与以往软件不同。这种组件模式，小巧、单一，对于开发人员来讲，开发成本较低。

在这里指出Webservices不是微软发明的，同样也不属于微软专有。Webservices是一个开放的标准，和HTTP、XML、SOAP一样。他们是一个工业标准而非微软标准，WS-I是为了促进WebServices互通性的联盟组织，最初是由IBM和微软所发起，其它的成员包括BEASystem、惠普计算机（HP）、甲骨文（Oracle）、英特尔（Intel）和SUN计算机（SunMicrosystem）。如今网络上存在的大多Webservices其实没有使用.NET构架，Webservices具有互操作属性，你同样可以使用Windows开发客户端来调用运行于Linux上面的Webservices的方法。

在.NET中，Webservice接口通常使用WebServicesDescriptionLanguage（WSDL）描述。WSDL使用XML来定义这种接口操作标准及输入输出参数，看起来很像COM和CORBA的接口定义语言（IDLS）InterfaceDefinitionLanguages。接口定义后就必须使用一些协议调用接口，如SOAP协议，SOAP源于一种叫做XMLRPC（XML远程进程调用remoteprocedurecalling）的协议，而Java则根据XML-RPC发展了自己的JAX-RPC协议用来调用WebServices。

组件设计编辑本段 回目录

.net

编写的组件或控件，最常规的作法是包括属性，方法以及事件等东东。但是如果想把组件或控件做得更加专业，就必须为属性或方法得供必要的说明或者是分类。而这一切都包含在组件的Attribute中。对于它，相信写过C#程序的都不会忘记，它就是包含在[]中的东东，比如[DefaultValue(“ASPcn”)]，[Description(“互动百科”)]等。

[Browsable(true|false)]设置属性或者事情是否在VS.net的属性窗口中出现。

[Category(“外观”)]设置属性或者事件在属性窗口中归于的组别。

[Description(“此控件于位于aspcn命名空间中”)]看英文就是知道了，这是关于属性的说明。它会出现在VS.Net属性窗口的说明之中

[DefaultValue(“互动百科”)]设置属性的默认值，值类型须与属性的类型一致。

[Bindable(true|false)]设置属性是否可以被捆绑。

[Localizable(true|false)]设置属性是否被本地化。

[DefaultEvent(“OnClick”)]也就是在Vs.Net设计窗口中，双击控件时默认连接的事件处理。当然这些还有好多。一般来说如果使用VS.Net开发。另外，如果需要对一个属性指定多个Attribute，可以使用两种方法。

第一种：

[DefaultValue(“互动百科”)]
[Description(“HI，欢迎你来”)]
[Category(“外观”)]
publicstringAdver()
{
...
}

这是最原始的，也可以将这些声明写在同一个“[]”中

[
DefaultValue(“互动百科”)，
Description(“HI，欢迎你来”)，
Category(“外观”)
]
publicstringAdver()
{
...
}

自动属性编辑本段 回目录

在做一个程序是离不开属性，特别是实体类。用指头一个一个的敲着get和set及局部的变量(Fields)，现在可好不用在重复敲那些东东了只要用到get和set，就和接口声明差不多。看个例子先，在.NET2.0下声明一个实体类要有如下做法。

.net

1publicclassPerson{
2
3　privatestringfirstName；
4　privatestringlastName；
5　privateintage；
6
7　publicstringFirstName{
8
9　　get{
10　　returnthis.firstName；
11　}
12　set{
13　　this.firstName=value；
14　}
15}
16
17publicstringLastName{
18
19　get{
20　　returnthis.lastName；
21　}
22　set{
23　　this.lastName=value；
24　}
25}
26
27publicintAge{

.net

28
29　get{
30　　returnthis.age；
31　}
32　set{
33　　this.age=value；
34　}
35}
36}

在.NET3.x中可以省了很多东西，代码也变得简单很多，代码如下：

1publicclassPerson{
2
3　publicstringFirstName{
4　　get；set；
5　}
6
7　publicstringLastName{
8　　get；set；
9　}
10
11　publicintAge{
12　　get；set；
13　}
14}

.net

从命名空间的命名、目录的划分与命名可以看出一个程序员是否有经验，是否很有经验。一个编程老手绝不允许架构混乱。.net开发中，一般目录名与命名空间名称是对应的。关于命名空间如何划分，目录如何分类，这个问题看似简单，实际上却比较复杂，虽然它不像动植物学有一套完整的分类学。

在.NetB/S架构中，一般分为如下三个主要的命名空间：

[公司名/作者名].[项目名].Business

[公司名/作者名].[项目名].Data

[公司名/作者名].[项目名].Web这三部分可以在一个project中，也可以分置三处。

目录分类与空间命名之难在于：分类因素是二维的，而分类却只是一维的。解释一下：分类是一维的，指一个词语只能代表一个分类名称的含义，无论同时表达两个含义；分类因素是二维的，指分类可以横向类别分类，也可以按纵向属性分类。假设正在开发一个电子商务图书网站，这个商务按照常规，它有用户中心，帮助中心，支付中心，商品中心等。的这个项目分为三个project，如下：

Sban.ZLBook.Business

Sban.ZLBook.Data

Sban.ZLBook.Web

在Sban.ZLBook.Web工程中，下设UserCenter、HelpCenter、PayCenter、ProductCenter等目录，这样的分类便是按类别横向分类。而在这些分类中，肯定都用到了图片，还有一些css样式文件，这些文件放在哪里？把它们放在Web工程的Images目录下(如果不另辟图片服务器的话)。如果文件太多，不好管理，其子目录又可以分为UserCenter、HelpCenter、PayCenter、ProductCenter等。如此，Images的目录的划分便是按纵向属性分类。

关于具体如何命名，没有什么通用的方法，要看具体项目。做的项目多了，架构才能见水平。命名空间与目录建议大写。不知道应该如何架构的时候，不妨翻一翻官方的类库。btw:flex工程中，包名(pakeage)与目录小写，而类名大写。

资源释放编辑本段 回目录

.net

在.NET1.x的C#、.NET2.0的各种语言中，有所谓的usingstatement，可保证自动dispose（释放）unmanagedobject（对象）所占用的资源，包括因未处理的exception而造成区块结束（但StackOverflowException除外），系统都会dispose资源。因此若您在using区块中建立了数据库的connection，即无须再手动closeconnection，亦无须再下Connection.Dispose（）、Command.Dispose（）等指令。

根据MSDNLibrary和市面上几本ADO.NET2.0原文书都有提到，在using区块中会自动去做dispose的动作。.NET的garbagecollector会自动释放不再使用的managedresources所占用的内存，不用程序员手动撰码；但unmanagedresources则需要程序员自行下Dispose（）去做处理，以让对象彻底终止unmanagedresources的使用。例如传统的做法，常会在try-catch-finallypattern中去呼叫Dispose方法；但若是数据库的联机，则必须有不同考虑，因为若任意下Dispose提早回收，也可能导致联机无法有效地被重复引用。
　
数据库和DataProvider都有支持ConnectionPooling机制，亦即在建立完数据库的联机后，当程序员呼叫Close方法关闭一个数据库的Connection对象时，.NET的DataProvider并不会将这个对象所占用的内存空间释放掉，而是将此对象暂存至Pool之中，以便待会可以再重复使用。
　
若在设定时间（默认为60秒）内，没有应用程序使用到此对象，或是呼叫了Dispose方法，则.NETDataProvider才会真正关闭这个联机，并由GarbageCollector自动将资源收回。因此，常有web程序员在网络上各讨论区提到，是否有必要在呼叫Close方法后，再呼叫Dispose方法，并将Connection设为Nothing（或Null）答案是不必要的。因为GC过一阵子就会自动回收未再被参照的联机，手动呼叫Dispose只不过提早回收的动作而已。而且若是该联机，可能会在短时间内被大量使用者同时存取的话，也应让其待在Pool中待命，而应避免手动呼叫Dispose方法，导致它被真正关闭并被回收，而无法有效地被重复使用。
　

.net

由于GC只会在系统闲置或内存不足时才启动，因此除非是使用频率非常繁复的资源，否则交由GC自行处理即可。而设为Nothing（或Null）也只是将Connection变量的位置清除（NullReference），事实上原来New出来的Connection对象还是存在。而Dispose方法是用来处理自行建立的Windows资源，但又不会自行释放的对象，如档案（开档与关文件）、GDI对象（直接由WinAPI叫用）。
　
.NET的VB/C#语言中都有的usingstatement.using语句算是简易版的try-finallypattern，可让程序员以较简便的写法尽早去释放资源，尤其最适用在有限的unmanagedresources上，例如：档案和串流I/O、Socket网络连接、FileHandle（档案控制代码）、COM组件、绘图和字形、数据库存取、WorkflowRuntime（WF）等的内存自动释放。usingstatement遇到例外时，也会抛出例外（throw），但不会去catch处理例外；因此若您想要自行处理例外的话，只能回归传统的try-catch-finally写法。
　
提供给usingstatement的对象必须实作IDisposable接口。若是自己写的class，只要实作System.IDisposable接口，即拥有Dispose方法。之后若引用usingstatement去释放这个class的instance，即会自动做object的Close（）、Dispose（）、设定为null（Nothing）这三种动作，不需要再自己手动处理。反而若是自己手动多下一次Close（），会让CLR浪费资源多做一次处理，反倒会影响程序“性能（performance）”。根据国外网站及ADO.NET2.0书籍证实，若using语句搭配CommandBehavior.CloseConnection一起使用，其重复关闭数据库联机的动作，会大幅地降低程序性能，处理时间甚至会多出84%以上（叫用ExecuteReader（）时，若搭配CommandBehavior枚举值（enumeratedvalue），可要求在查询完成后，自动关闭数据库联机）。
　
此外，usingstatement也可多层巢状地使用，例如：第一层的usingstatement里包SqlConnection的宣告及instance的新增，第二层包SqlCommand，第三层包SqlDataReader。亦可在巢状的usingstatement中指定多种的系统资源，包括数据库的transaction交易处理。