一、概述
Windows Communication Foundation(WCF)是由微软发展的一组数据通信的应用程序开发接口,可以翻译为Windows通讯接口,它是.NET框架的一部分。由 .NET Framework 3.0 开始引入。
WCF的最终目标是通过进程或不同的系统、通过本地网络或是通过Internet收发客户和服务之间的消息。
WCF合并了Web服务、.net Remoting、消息队列和Enterprise Services的功能并集成在Visual Studio中。
WCF专门用于面向服务开发。
二、基于Asp.net 的应用程序开发与面向服务开发
在基于Asp.net 的应用程序开发中,我们由客户机的浏览器访问应用程序服务器,然后通过应用程序服务器中的数据库连接去连接数据库服务器,读取或是操作数据,有时候可能会多一个文件服务器。大家可以观察到,基本上所有的应用都放在了一台服务器上,但对于一个,由于业务上的需要(如:与外部系统交互),一台服务器很难支持所有的应用。我们再看下面的图:
客户机使用浏览器访问服务器A,服务器A为了业务需要与其他各种应用部署在服务器B、C、D....再通过WCF技术互相通信,相互访问...然而面向服务的好处不仅仅在此,他还提供了不同语言不同操作系统的可交互性..由于本文不是介绍SOA的文章,感兴趣的同学可以参见:SOA
三、第一个WCF程序
1. 新建立空白解决方案,并在解决方案中新建项目,项目类型为:WCF服务应用程序。建立完成后如下图所示:
2.删除系统生成的两个文件IService1.cs与Service1.svc。
3.添加自定义的WCF【服务文件】User.svc,此时vs2010会自动生成WCF接口文件IUser.cs,我们在IUser中定义WCF方法ShowName,在User.svc.cs对该接口的方法进行实现。
代码如下:
1 using System.ServiceModel;
2
3 namespace WCFService
4 {
5 [ServiceContract]
6 public interface IUser
7 {
8 [OperationContract]
9 string ShowName(string name);
10 }
11 }
12
13
14 namespace WCFService
15 {
16 public class User : IUser
17 {
18 public string ShowName(string name)
19 {
20 string wcfName = string.Format("WCF服务,显示姓名:{0}", name);
21 return wcfName;
22 }
23 }
24 }
大家可以看到,在WCF中的接口与普通接口的区别只在于两个上下文,其他的和我们正常学习的接口一样。定义这个上下文要添加System.ServiceModel的引用。
[ServiceContract],来说明接口是一个WCF的接口,如果不加的话,将不能被外部调用。
[OperationContract],来说明该方法是一个WCF接口的方法,不加的话同上。
此时我们的第一个WCF服务程序就建立好了,将User.svc“设为起始页”,然后F5运行一下试试,如下图所示,VS2010自动调用了WCF的客户端测试工具以便我们测试程序:
我们双击上图中的 ShowName() 方法,出现如下图:
在请求窗口中的值中输入参数“你的姓名”,然后点击“调用”,在响应窗口中会出现返回值“WCF服务,显示姓名:你的姓名”,说明测试成功,点击下面的XML也可以看到XML的数据传输。我们现在建立好了服务的应用程序和业务逻辑,即非常简单的打印姓名的方法,测试也成功了。那么我们怎么用呢?
四、场景
我们设计的场景是在生产中经常应用的场景,把WCF程序寄宿在IIS之上。假设场景如下:A服务器和B服务器。我们把我们刚刚建立的WCF程序“部署”在B服务器上(本教程的A,B服务器都放是我自己的一台机器),我们的目标是在A服务器的应用程序来访问B服务器的WCF程序,实现服务器端的应用程序通讯。
五、将WCF程序寄宿在B服务器的IIS之上
首先我们将WCF应用程序发布一下,然后部署在B服务器的IIS之上,如下图所示:
鼠标右键浏览Uesr.svc,在游览器中出现如下图所示,说明服务部署成功。
上图中的http://localhost/User.svc?wsdl即为我们要引用的服务地址。
六、在客户端[A服务器]创建服务的引用
我们这里以Web应用程序为例,建立地物理地址为本机,但是大家可以想像成B服务器是远程计算机,localhost为一个其他的IP地址。
新建解决方案,并且创建ASP.NET Web应用程序的项目。命名为:WCFClient,如下图所示:
(1)新建Asp.net页面,命名为:WcfTest.aspx。
(2)添加在第五步中部署的服务的引用。如下图所示:
此时弹出添加服务引用的窗体,如下图所示:
我们在地址里写上我们寄宿在IIS上的WCF服务的地址服务路径,此处为:http://localhost/User.svc?wsdl,在名称空间处填写WCFService[此名称空间要在下面的客户端中引用]然后点击“前往”-->“确定”按钮。此时我们完成了对服务的引用。我们再次查看解决方案,里面多了Service References的文件夹,通过资源管理器打开后里面多了些文件,这些文件用于客户端向服务端的调用,现在先不用管他。
七、使用WCF服务端的方法
WcfTest.aspx的代码如下:
1 <%@ Page Language="C#" AutoEventWireup="true" CodeBehind="WCFTest.aspx.cs" Inherits="WCFClient.WCFTest" %>
2
3 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
4 <html xmlns="http://www.w3.org/1999/xhtml">
5 <head runat="server">
6 <title></title>
7 </head>
8 <body>
9 <form id="form1" runat="server">
10 <asp:TextBox ID="txtName" runat="server"></asp:TextBox><br />
11 <asp:Button ID="btnSubmit" runat="server" Text="测试WCF服务" OnClick="btnClick" />
12 </form>
13 </body>
14 </html>
15
16 using System;
17 using System.Collections.Generic;
18 using System.Linq;
19 using System.Web;
20 using System.Web.UI;
21 using System.Web.UI.WebControls;
22
23 //引用WCF服务的名称空间
24 using WCFClient.WCFService;
25
26 namespace WCFClient
27 {
28 public partial class WCFTest : System.Web.UI.Page
29 {
30 protected void Page_Load(object sender, EventArgs e)
31 {
32
33 }
34
35 protected void btnClick(object sender, EventArgs e)
36 {
37 UserClient user = new UserClient();
38 string result = user.ShowName(this.txtName.Text);
39 Response.Write(result);
40 }
41 }
42 }
上面中的UserClient类是在添加引用的时候生成的服务端User类的客户端代理类,一般客户端代理类名称都会是**Client。我们运行一下看下效果。
通过以上的例子,我们完成了由A服务器的应用向B服务器中WCF提供的方法的调用。这个例子比较简单,对于经常开发B/S结构应用程序的同学们来说比较好理解。
八、说明:因为网上的入门教程比较少,本教程只做入门,后面会继续讲些其他入门的东西,深入的请看园子里:Artech 大哥的文章。
九、代码下载:
八、版权
Scrum初体验
敏捷项目管理我们团队已经试行了近三轮,现将在实践过程中的体验分享给大家。
一、写在前面
敏捷项目管理实施前,一直在倡导做项目、需求要敏捷,在保证质量的同时尽可能的快速完成开发任务,但很少有真正实践的机会。之前的需求开发流程基本如图1所示。
(图1 基本开发流程图)
该流程最大优点是需求能快速上线。需求方提出的需求,基本都希望能尽快上线。各开发针对自己开发的需求,在需求方要求的时间内完成对需求的开发,发布上线。
缺点:
1)不利于产品发展。开发人员满足于开发眼前需求,缺少对产品的整体认识,对产品发展的贡献不足;
2)不利于开发人员的成长。需求一个接一个的开发,纯粹为开发需求,缺少沉淀和总结,开发人员很累;
3)缺少团队合作。每个开发人员各自为战,欠缺开发人员之间的沟通。
二、体验Scrum
基于以上需求开发流程,我们尝试改变原有的方式,拟采用两周一迭代的敏捷开发模式。
1) 第一轮迭代
由于先前对于敏捷开发的认识并不是很足,于是乎第一次的迭代基本可用“摸着石头过河”来形容。整体周期如图2所示:
(图2 第一轮迭代周期图)
该迭代以2周为一个周期,整体开发周期为6天,2天为集成测试时间,PM资源权重为0.5。回顾这一次迭代,整个过程还是比较顺利,主要遇到以下几个问题:
1)紧急需求的插入(新增3个需求,约4人/日的工作量);
2)对于一句话的需求,工作量评估不足(如,“XXX页面增加XX功能”需求。评估1.5人/日,实际需要3人/日。)
处理办法:
1) PM压缩部分时间投入于紧急需求的开发;分配部分任务给项目成员(其他任务完成较快的开发);
2) 开发晚上加班处理对于工作量评估不足的需求;项目组成员共同协调处理。
总得来看,采用敏捷开发与之前的变化:1)每天晨会,开发间的沟通多了;2)开发对于整体需求认识度提升;3)项目成员开始相互协作,共同解决问题;4)紧急需求能快速响应,项目组内部消化。
2) 第二轮迭代
针对第一轮遇到的不足点(需求评估不足)以及项目开发周期的试用总结,对于第二轮迭代做了相应调整。如图3所示:
(图3 第二轮迭代周期图)
红色部分为变化的点。其中在迭代任务分配完,进行了整体需求的评审;开发周期从6天调整为7天;集成测试2天调整为1天;PM资源权重从0.5调整为0.7;项目完成后,增加了项目总结环节。
回顾该迭代,主要遇到的问题有以下几点:
1)紧急需求的插入;2)需求评审较晚,影响开发人员的开发时间;3)前端开发工作量评估不足;
针对以上问题的解决办法:
1) 周末PM加班处理紧急需求;2)相应开发加班赶进度;3)项目总结。
3)第三轮迭代
针对第二轮迭代遇到的主要问题(需求评审太迟,影响工作量评估,影响开发时间),将需求评审的时间再往前移。如图4所示:
(图4 第三轮迭代周期图)
第三轮迭代目前正在进行,已经感知到的问题有以下两个:1)需求评审还是太迟,影响工作量评估及部分开发工作;2)整个周期缺少设计环节,缺少对于技术的沉淀。
针对以上两个问题,拟对迭代再次调整。如图5所示:
(图5 拟第四轮迭代周期图)
将需求评审再次提前。需求评审完后,指定相应开发跟进需求,进行相关的设计工作,拟减轻迭代中的开发任务。
三、总结
以上迭代流程并不是最优,还在不断地实践中优化。总体感觉,敏捷开发是不断自我进化的一个过程。通过不断地实践,在实践过程中进行不断地总结,不断完善和优化,使项目朝着健康、有序、向上的方向发展。