基于.NET Web Service的动态接口设计与实现 

摘要：由于智能手机的普及和社会信息化的不断发展，人们希望能通过手机或者平板的APP对原有B/S架构的信息化系统进行操作，因此这些系统就需要为移动端的APP提供访问系统内部业务逻辑的接口，而如何为APP快速高效地提供这些接口一直是个难题。如果服务器只向外界暴露一个接口，而外部应用只需通过调用该接口就可以完成服务器中所有的业务逻辑，则会大大降低接口的开发时间和成本。该类接口被称为“动态接口”，设计并实现了基于Web Service的动态接口，以提高接口开发效率。

关键词：APP；Web Service；动态接口

DOIDOI：10.11907/rjdk.161484

中图分类号：TP319

文献标识码：A文章编号文

章编号：16727800（2016）009008203

基金项目基金项目：

作者简介作者简介：丁易难（1991-），男，安徽安庆人，西安工程大学计算机科学学院硕士研究生，研究方向为计算机应用开发。

0引言

目前，大部分企业都搭建有自己的信息化平台，B/S架构的跨平台性和易用性，使得B/S架构被广泛应用。然而，随着移动网络技术及移动设备性能的快速发展，“移动办公”越来越受到企业青睐。很多企业都纷纷希望能拥有一个手机APP版的企业信息化平台，该平台向外界提供一个访问系统内部的BLL层（Business Logic Layer）的接口，以便其它形式的用户终端调用。在.NET平台下，一般都是采用微软提供的Web Service技术，向外界暴露接口。一般情况下，系统开发者会在Web Service层里，将系统中BLL层的每个类中的每个方法写一个同样的Web Method为外界终端提供访问内部BLL层的接口。但是，一个系统的业务逻辑众多，会有大量的业务逻辑的对象和方法。使用上述方法，会导致开发人员的工作量巨大。如果能在Web Service里，只写一个Web Method，即在本系统的Web Service层中只向外界提供一个接口，通过外部终端向服务器调用此接口，并传递相关参数，进而“动态地”调用系统内部已实现的各种业务逻辑方法，就会节省开发人员为系统开发接口而耗费的大量的工作时间。鉴于此，本文主要阐述了如何在基于.NET平台的Web Service技术下，完成上述“动态接口”设计与实现。

1相关技术

1.1Web Service

Web Service是一种跨编程语言和跨操作系统平台的远程调用技术[1]。Web Service技术能使得运行在不同机器上的不同应用无须借助附加的、专门的第三方软件或硬件， 就可相互交换数据或集成。依据Web Service规范的实施应用， 无论它们所使用的语言、 平台或内部协议是什么， 都可以相互交换数据[2]。Service是自描述、 自包含的可用网络模块， 可以执行具体的业务功能。Web Service也很容易部署， 因为它们基于一些常规的产业标准以及已有的一些技术，诸如标准通用标记语言下的子集XML、HTTP。Web Service减少了应用接口的花费，为整个企业甚至多个组织之间业务流程的集成提供了一个通用机制。

1.2JSON

JSON是一个轻量级的数据交换负载格式[3]。它是基于JavaScript编程语言ECMA-262 3rd Edition-December 1999标准的一种轻量级数据交换格式，主要用于跟服务器进行数据交换。与XML相比，JSON更加简单和灵活[4]。JSON还具有可读性、可扩展性和编码解码难度低等特点。因此，本文设计的基于Web Service的动态接口所传递的参数中，或者返回的结果中若有系统的对象实体Model，则需要将其转成JSON格式的字符串，以方便客户端和服务端解析。

1.3.NET反射技术

反射是C#.Net中获取运行时类型信息的方式[5]，它也是.NET中的重要机制，提供了封装程序集、模块和类型的对象（Type类型）。可以使用反射动态创建类型的实例，将类型绑定到现有对象，或从现有对象获取类型并调用其方法或访问其字段和属性。

2基于Web Service的动态接口实现原理

如图1所示，“动态接口”的基本实现原理是，客户端在调用Web Service提供的接口时，客户端的代理类会把调用的相关数据封装成SOAP协议（简单对象访问协议）的XML格式，通过HTTP协议向服务器端传递相关参数（例如调用业务逻辑层的名称、方法以及方法参数），服务器端接收到这些参数并解析后，通过使用反射技术，动态地创建要调用业务逻辑的方法所在类的实例，再通过该类的实例调用其方法，最后通过网络将方法的执行结果返回给调用方，从而实现后台业务逻辑的“动态”调用。

3动态接口具体实现

（1）创建Web Service。首先在Visual Stdio中新建一个Web项目，然后新建一个Web Service类（后缀名为.asmx），取名为DyInterface.asmx。

（2）定义WebMethod。实现“动态接口”需要用到.NET的反射机制，而在使用反射技术时，程序需要知道反射调用的是哪个类的哪一个方法，并且调用的方法可能需要传递参数，因此需要在Web Service类中定义这个动态接口的WebMethod时需要定义3个形参：bllName（业务逻辑的类名称）、methodName（要动态调用的业务逻辑类中的方法名称）、param（方法的参数）。具体定义动态接口方法的C#代码如下：

[WebMethod]

public string InVoke（string bllName，string methodName，string param）

{

//ToDo...

}

（3）创建外部客户端需要调用的业务逻辑类的实例。要调用类中的方法，就要获得这个类的实例。传统实例的方法一般是通过关键字new来获得，然而通过new获得类的实例需在程序中事先写好，但是动态接口并不会提前知道客户端需要调用的是哪个业务逻辑类，所以通过传统new的方式获得类实例不能满足本次接口设计需求。因此只有通过形参bllName的值才能知道需要调用是哪一个业务逻辑的类，再利用反射技术，载入业务逻辑层的程序集（BLL），再通过CreateInstance的方法，动态地生成该业务逻辑类的实例。代码如下：

dynamic bll = Assembly.Load（"BLL"）.CreateInstance（"BLL" + bllName）

这里利用了C#的动态类型的关键字“dynamic”，来接受创建的业务层的实例。该动态类型是在程序运行期间，动态获取示实例的具体类型，从而避免了类型强制转换的步骤。

（4）解析所调用方法中的具体参数。由于是基于Web Service的动态接口设计，且面向的是不同平台的客户端，因此为了屏蔽不同平台差异性，本次动态接口的param参数定义为string类型。由于本次设计的动态接口只提供了一个调用方法参数的形参（param），这样，当调用业务逻辑层的方法时，需要传递的参数有多个，或者传递的是系统中的对象实体（Model）时，就需要预先约定好参数传递的格式，以便在Web Service中解析它们。因此，参数（param）格式可以这样约定：如果要调用的业务逻辑方法有N个参数，则依次按原方法参数的顺序参数排放好，并以“*”隔开；如果有些参数是系统中的对象实体，则将其转成JSON形式的字符串，并在JSON串前面加一个"@"符号，以区分普通参数与实体对象参数。若要调用的方法没有参数，则传空值。依照上述约定，就可以解析这些参数了，具体代码如下：

List