REST API 出现之前，SOAP (Simple Object Access Protocol) 一直都是基于 web 的标准协议，虽然现在 REST 大行其道，但在平时开发中总会遇到对接第三方服务采用的是基于SOAP协议的场景，在这篇文章中，我们将会讨论如何在 ASP.Net Core 中对接 WCF。

创建 WCF

WCF 是一个安全可靠的消息平台，它提供统一的编程模型便于开发基于面向服务的应用程序，你可以使用 WCF 构建基于 SOAP 协议的服务，并使用 xml 作为数据交换格式，或者基于 REST 的 json 数据交换格式。

这一节中首先创建一个 WCF SOAP 服务，在创建项目模板的时候选择 WCF Service Application 即可，如下图所示：

值得注意的是，WCF 通常由以下几个部分组成。

• Service 类

• Service 契约

• Operation 契约

• Endpoints 端点

• Hosting 环境

当要使用 WCF，需要在类和方法上分别加上：ServiceContract 和 OperationContract，下面的代码展示了一个契约类仅包含一个契约方法的代码定义。

    [ServiceContract]
    public interface IAuthorService
    {
        [OperationContract]
        List<string> GetAuthorNames();
    }

接下来定义一个 AuthorService 服务类实现一下 IAuthorService 接口，下面的代码展示了 AuthorService 类的具体定义。

    public class AuthorService : IAuthorService
    {
        public List<string> GetAuthorNames()
        {
            List<string> lstAuthors=new List<string>();
            lstAuthors.Add("Joydip Kanjilal");
            lstAuthors.Add("Steve Smith");
            lstAuthors.Add("Michael Stevens");
            return lstAuthors;
        }
    }

这就是构建 WCF 服务的所有步骤，接下来就可以打开浏览器对服务进行简单测试了。

在 ASP.Net Core 中使用 SOAP 服务

与传统的 ASP.NET 不同，ASP.Net Core 中并没有 Add Service Reference 选项去添加对 WCF 服务地址的引用，新的操作方式需要利用 Microsoft WCF Web Service Reference Provider 来进行服务引用，如下图所示：

当点击图中的 Finish 之后，VS会自动帮你完成一系列的初始化，比如从SOAP服务中下载元数据，生成客户端的代理代码，自动生成 Reference.cs 文件，等等。

好了，接下来可以在 Controller 中初始化 SOAP Service ，然后再调用 Service 端的 GetAuthorNamesAsync() 方法，如下代码所示：

        [HttpGet]
        public async Task<string[]> Get()
        {
            ServiceReference1.AuthorServiceClient authorServiceClient=new ServiceReference1.AuthorServiceClient();
            var data=await authorServiceClient.GetAuthorNamesAsync();
            return data;
        }

WCF Connected Service 是 Visual Studio 的一个扩展插件，它允许在 ASP.Net Core 项目中实现对 WCF 服务的引用，当然，除了WCF还可以引用 Azure Storage 服务，关于 Azure Storage 的更多细节，我会在后面的文章中和大家细聊。

译文链接：https://www.infoworld.com/article/3323584/how-to-consume-a-wcf-soap-service-in-aspnet-core.html

　软件架构逻辑

　　框架从层次结构上分主要分为：表示层、服务层、业务层、数据层

　　◆表示层

　　表示层由UI(User Interface)和UI控制逻辑组成。

　　c/s选用wpf+智能客户端,b/s选用asp.net mvc

　　WPF的出现解决了三个问题:

　　(1) 更快速的去开发更丰富的用户体验:使用WPF,可以在更加快速的时间内开发出来更加丰富的界面,满足用户的需求。WPF 借助 XAML 来利用标记而不是编程语言(如 C#)来构造精美逼真的用户界面 (UI), 只要稍微具备一些HTML基础知识，就可以快速地掌握XAML中的大部分内容。

　　(2) 消除用户界面差异:wpf可以以IE为宿主的。或Silverlight

　　(3) 软件开发团队的协作问题: 在软件团队中,我们比较熟悉Developer、DBA、Tester、IT Pro、Architect等。Designer可能往往被我们忽视,但实际上,Designer的工作成果才是与客户距离最近的。而且Designer与Developer如何配合工作,是很多团队所头疼的,而WPF正可以解决此问题。

　　智能客户端的优势

　　1)充分利用终端设备的优势

　　2)能够调用wcf

　　3)支持在线和离线两种状态

　　4)能够如同Web应用程序一般简单方便的部署

　　asp.net mvc内置AJAX支持。

　　本身含的MVC(模型-视图-控制器)和本系统MVVM(Model-View-ViewModel)就是双胞胎，在demo里已经有很好的集成

　　*注：因xaml和html是标记语言，此层大部分可用代码生成器生成。

　　◆服务层

　　采用微软的WCF，Windows Communication Foundation (WCF)是Microsoft为构建面向服务的应用提供的分布式通信编程框架平台，是.NET Framework 3.5的重要组成部分。使用该框架，开发人员可以构建跨平台、安全、可靠和支持事务处理的企业级互联应用解决方案。WCF从一开始就是工程化的，能够简化应用程序的开发与部署，降低开发成本。用于构建面向服务的应用程序，不管这些程序是独立的桌面应用程序，还是Web应用程序和服务，还是高端的企业应用程序。

　　◆逻辑、业务层

　　业务层封装了实际业务逻辑，包含数据验证，事物处理，权限处理等业务相关操作，是整个应用系统的核心。因此设计一个能够真实反映实际需要的业务层是非常必要的，我们将实际业务具体分为业务数据与业务操作两部分。

　　l 业务数据

　　Domain Model则是根据实际业务按照现实方式用OO思想建模，这样很适合业务复杂的系统。通常采用自定义数据实体(Custom Data Entity)方式表达。自定义数据实体，有着良好的性能，编译时的类型检查，数据表现方式非常直观符合实际业务的操作方式等优点，但需要自己定义维护类，在分布式环境下需要自己编写序列化方法。

　　此阶段负责数据交换(传输)的业务实体被称之为DTO(Data Transfer Object)。

　　DTO要能够支持：数据绑定、数据验证、历史记录、级联触发、合并集合、序列化与反序列化，要实现一个大的递归，从其中的任何一个对象开始，能够找出整个传递的所有数据。

　　(1)、数据的绑定支持。要实现IEditableObject接口，对于状态的变化要实现INotifyPropertyChanged接口，这样才能够实现数据的触发，这样就要实现一个对象能够找到其所有的集合，一个集合要能够其所有的对象，这样一样，就必须实现从对象、集合、对象的递归，再深入一点，就实现了数据的级联触发，实现了双向数据触发、绑定。数据源的每个属性变更，要能够在界面上反映出来，绑定界面的改变，能够记录到后台的数据源，并且要能够支持回滚。对于容纳这些数据的ObservableCollection集合也支持绑定处理。

　　(2)、数据验证。实现IDataErrorInfo接口

　　(3) 对于历史记录。当实现IEditableObject这个接口，则必然实现了历史记录。能够找到集合的所有更改的记录，包括删除的记录。对于单个对象而言是能够得到历史记录和当前数据，对于集合而言，则能够找出差异集，同时，集合也要具备集合回滚的功能。

　　(4) 级联触发，则是在实现数据绑定的基础上的，对于常见的主从结构，当从对象的一个属性改变了，要能够自动通知其所在的集合、集合再通知所在的对象数据改变了，如果是多层结构，则能够自动的从最底层开始一路通知到顶层。

　　(5)合并集合、集合的处理。集合的处理与数据绑定是直接相当的。数据源找出差异集之后，要对差异集进行处理，处理完之后，要对原始集合进行更进一步的处理，要把两个集合进行合并处理，主要是为了同步引用。

　　(6)同时，另外要实现的就是Data与SDO之间的转换以及其他格式的数据与SDO、Data数据之间的数据转换，比如Binary/Xml/Text/Key/文件/等，最基本的是SDO与Data之间的转换，这些转换根据需要，有时候是单向的，有时候是双向的，根据业务需求而定。

　　(7)序列化与反序列化，主要是涉及到Binary和XML序列化。

　　l 业务操作

　　业务操作负责对业务数据进行各种业务相关的处理，例如验证，流向，整合，事物，权限等，但它不负责有关对数据源的操作。

　　采用整合业务数据与业务方式来操作，将业务数据与相关的业务操作封装在一起称为业务实体，业务实体作为统一的业务层为表示层提供服务，同时也负责作为DTO在各个层次间传输，这样完整的Domain Model设计方式，每个业务实体都可以做为一个单独组件形式存在，对于组件化复用有着莫大的好处。

　　◆数据层

　　数据层的宗旨就是为数据源提供一个可供外界访问的接口，我们应该选用一种能够提供数据源无关的抽象数据访问接口并通过在其下挂接各种不同的DataProviador来访问数据源的数据层组件，这样做便于移植到不同的数据源上。

　　从纷繁芜杂的关系数据模型中抽象出概念模型。这样开发人员可以只需着眼概念模型，而不必要去关心纷繁芜杂的关系数据模型，从而提高开发效率。那么如何能够做到这一点?

　　答案就是：Linq 和 ADO.NET Entity Framework

　　l LINQ几乎支持你所期望的所有数据源：数据对象、SQL Server数据库、XML和数据集，当然也支持ADO.NET Entity(LINQ to Entities),LINQ有如下优势：

　　1、 无需复杂学习过程即可上手

　　下面我给出一个简单的C#示例。

　　String[] QueryString=

　　{ "One", "Two", "Three", "Four", "Five" };

　　要想查找其中长度大于3的字符串，你可以使用以下查询语句：

　　var ThisQuery=

　　from StringValue

　　in QueryString

　　where StringValue.Length > 3

　　select StringValue;

　　2、 编写更少代码即可创建完整应用。

　　3、 更快开发错误更少的应用程序。

　　4、 无需求助奇怪的编程技巧就可合并数据源。

　　5、 让新开发者开发效率更高。

　　l ADO.NET Entity Framework包括

　　1. 实体数据模型(Entity Data Model),开发人员通过EDM抽象出非常合适的模型。

　　2. 非常强大的client-view/mappping引擎，用于映射数据关系

　　3. Entity SQL语言和LINQ查询对EDM schemas的全面支持

　　4. ojbect services layer供您选择以何种方式去处理查询结果。比如(行，列或作为对象)。

　　5. 提供一个开放的模型使ADO.NET Entity Framework可以处理其他的数据存储。

　　6. Entity Framework 实现了乐观的并发模式(Optimistic Concurrency Model)

　　7. 事务处理

　　三、具体功能简述

　　3.1工作流解决方案

　　工作流引擎：该部分为工作流模型的核心部分，用于生成、管理、角度和监控工作流的各个活动执行情况，并实现相应的人机交互。由于采用XPDL等语言定义的工作流文件记载了相应的业务逻辑，隐藏工作流引擎通过解析该文件来了解业务流转的逻辑。然后依据某种运行模式按照解析出来的业务逻辑进行驱动，最终实现业务流程的流转。

　　工作流定义接口：通过该接口可以进行工作流程的分析、建模、描述和归档等工作，并将设计完毕的业务流程生成工作流引擎能够识别的语言。

　　工作流客户接口：处理工作流运行过程中需要人为参与的操作。

　　工作流调用应用程序接口：工作流引擎调用外部应用程序的规范。

　　工作流引擎协作接口：不同工作流引擎之间的协作。

　　工作流管理监控接口：监控和管理工作流所有实例状态。

　　3.2多语言&用户自定义标签方案

　　数据库结构

　　3.3消息发布/订阅系统方案

　　使用WCF创建发布/订阅系统有多种不同的方式，

　　(1)使用回调契约的发布/订阅系统

　　(2)使用MSMQ实际通用组播的发布/订阅系统

　　(3)使用流的发布/订阅系统

　　方法1,2适合通知数据量较大并且发布频率比较低的应用场景。

　　当通知的数据量较小而且发布频率又较高时，应该使用方法3。

　　3.4报表&打印方案

　　四、系统平台&支撑组件

　　l Wpf (UI)

　　l Asp.net mvc(UI)

　　l ClickOnce(智能客户端。可自动升级，离线操作)

　　l Linq(借助于LINQ技术，我们可以使用一种类似SQL的语法来查询任何形式的数据,普通开发人员不必学习MsSql, mysql, orcale, access等数据库语法，节省开发时间)

　　l ADO.NET Entity(让应用程序可以用完全对象化的方法连接与访问数据库, 修改Provider就可迁移到不同的数据库)

　　l IIS6或以上

　　l Windows server 2003或以上

　　l WCF(服务层)

　　l Unity(是微软模式与实践团队开发的一个轻量级、可扩展的依赖注入&反转控制容器)

　　l SQL Server Compact Edition(用作智能客户端离线操作)

　　l WF(Microsoft Windows Workflow Foundation是一个可扩展框架，用于在 Windows 平台上开发工作流解决方案)

　　五、系统网络结构

、SOA平台简介

1.1、概述

SOA（service-oriented architecture，也叫面向服务的体系结构或面向服务架构）是指为了解决在Internet环境下业务集成的需要，通过连接能完成特定任务的独立功能实体实现的一种软件系统架构。SOA是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。

传统的Web（HTML/HTTP）技术有效的解决了人与信息系统的交互和沟通问题，极大地促进了B2C模式的发展。WEB服务(XML/SOAP/WSDL）技术则是要有效的解决信息系统之间的交互和沟通问题，促进B2B/EAI/CB2C的发展。SOA（面向服务的体系)则是采用面向服务的商业建模技术和WEB服务技术，实现系统之间的松耦合，实现系统之间的整合与协同。WEB服务和SOA的本质思路在于使得信息系统个体在能够沟通的基础上形成协同工作。

对于面向同步和异步应用的，基于请求/响应模式的分布式计算来说，SOA是一场革命。一个应用程序的业务逻辑（business logic）或某些单独的功能被模块化并作为服务呈现给消费者或客户端。这些服务的关键是他们的松耦合特性。例如，服务的接口和实现相独立。应用开发人员或者系统集成者可以通过组合一个或多个服务来构建应用，而无须理解服务的底层实现。举例来说，一个服务可以用。NET或J2EE来实现，而使用该服务的应用程序可以在不同的平台之上，使用的语言也可以不同。

1.2、SOA基本特征

SOA的实施具有几个鲜明的基本特征。实施SOA的关键目标是实现企业IT资产的最大化作用。要实现这一目标，就要在实施SOA的过程中牢记以下特征：

1. 可从企业外部访问
2. 随时可用
3. 粗粒度的服务接口分级
4. 松散耦合
5. 可重用的服务
6. 服务接口设计管理
7. 标准化的服务接口
8. 支持各种消息模式
9. 精确定义的服务契约

1.3、为什么选择SOA

　　不同种类的操作系统，应用软件，系统软件和应用基础结构（application infrastructure）相互交织，这便是IT企业的现状。一些现存的应用程序被用来处理当前的业务流程（business processes），因此从头建立一个新的基础环境是不可能的。企业应该能对业务的变化做出快速的反应，利用对现有的应用程序和应用基础结构（application infrastructure）的投资来解决新的业务需求，为客户，商业伙伴以及供应商提供新的互动渠道，并呈现一个可以支持有机业务（organic business）的构架。SOA凭借其松耦合的特性，使得企业可以按照模块化的方式来添加新服务或更新现有服务，以解决新的业务需要，提供选择从而可以通过不同的渠道提供服务，并可以把企业现有的或已有的应用作为服务， 从而保护了现有的IT基础建设投资。

2、服务的定义

2.1、概述

　　关于SOA平台服务的定义，目前来说一般有两种形式，一种是定义标准接口的形式，一种是以标准的WebService的形式来下定义服务的实现。

在上图中是以接口的形式来定义SOA平台服务的，RDIFramework.NET的SOA实现也是采用这种方式。具体的实现是以.NET技术的WCF来实现的，服务可以以以下几种方式寄存（发布）：Windows服务模式（常用）、WinForm界面模式、IIS服务模式等等。在后面的文章我们会分别介绍。

2.2、SOA服务设计原则

一、SOA要求一致性

有很多可用于创建、发布、发现和调用服务的候选技术。SOA 应提供一个参考体系结构，以指定服务提供者和使用者将使用的特定机制；我们应以在 SAO 所有参与者间实现一致性为目标。此类一致性可以减少开发、集成和维护工作。

如果需要使用参考体系结构之外的元素，我们推荐使用补充性方法。例如，假如我们为服务发布和发现选择的机制是 UDDI，但某个特定的开发团队已在使用一个基于其他存储库技术的开发流程，此时该如何处理呢？我们将选择投入精力将该团队的服务同时发布到两个存储库。这样，现有的服务使用者就可以使用其熟悉（但可能并不标准）的存储库了。而运行于公共 SOA 基础结构上的使用者则可以为所有服务使用标准存储库——例如 UDDI。

二、SOA 简化开发

我们希望任何企业级的 SOA 基础结构都具有可伸缩性和弹性；还应包含行业级的企业服务总线（Enterprise Service Bus，ESB）和安全技术。或者，换种说法，以 SOA 为目标的服务和流程的开发人员可利用成熟的中间件，依赖 SOA 基础结构提供问题的解决方案，如身份验证、消息转换和可靠消息交付。

这些中间件功能的提供应以一个重要的原则为基础：服务和流程开发人员应远离中间件实现的复杂细节。我们的理想目标是，在我们的 SOA 环境中工作的开发人员应只需要业务领域的相关知识和基本的编程技巧。

服务具有标准的、经过正式定义的可由计算机处理的接口

了解了工具和代码生成在 SOA 实现中可扮演重要角色之后，我们现在要强调使用可由计算机处理的接口的重要性。当使用定义良好的可由计算机处理的语言描述了接口时，实际上就为各种工具支持功能提供了支持。我们希望改善分离状况，因此我们强烈建议使用 WSDL 之类正式定义的开放标准语言，而不要使用专用格式。

可由计算机处理的方法的概念应该从服务接口描述（如 WSDL）扩展到所有其他形式的声明信息或元数据。只有同时强调声明技术和可由计算机处理的元数据，才能将其相关的复杂性从业务应用程序开发人员转移到基于标准的中间件中。新兴的 WS-Policy 之类的技术在支持此方法方面充当着重要的角色。

三、服务应设计为可重用

服务设计人员应该记住，他们所开发的任何服务都可能成为可重用资产。设计人员不应只关注服务的最初使用者的需求，而应该进行更为广泛的业务分析，以确定更全面的需求。我们建议，设计人员应考虑服务可能的发展方向：

设计必须能适应不断增加的吞吐量；如果服务在使用服务的数量增加的情况下仍可成功运行，那么使用率也会成级数递增。

如果使用服务的数量增加，则数据量和并发数据访问模式可能会与最初投入使用时的情况大为不同。

我们必须对服务请求的未来增长进行预计；新使用者可能需要其他的功能，或者需要对现有功能进行更改

四、服务应具有精心选择的粒度

在选择服务粒度时，我们可能需要在多个因素间进行折衷，如可维护性、可操作性和易用性。任何给定的 SOA 都应向服务设计人员提供指南，以便确定此类折衷方案。

五、服务应是内聚而完整的

既然认识到了在确定服务粒度时需要考虑周全，那么在确定哪些操作应组成服务时有什么注意事项呢？我们认为有两个对象设计概念很有用：内聚性和完整性。

六、服务应对实现细节进行封装

我们封装服务实现的细节——所用的算法和资源——的动机在于增加服务使用者和提供者之间的分离，从而为将来扩展提供灵活性。

七、操作设计应考虑并发性

3、框架SOA发布方式

RDIFramework.NET框架的SOA（WCF服务端）可以通过以下几种方式进行寄存（发布）： 以Windows服务方式寄存，以WinForm形式寄存和以IIS形式寄存。

要想框架以WCF模式运行，首先必须配置RDIFramework.NET框架可运行文件所在文件夹的“Config.xml”文件，找到“软件服务提供程序”项，其取值有两种：RDIFramework.ServiceAdapter与RDIFramework.ServiceClient

系统默认为“RDIFramework.ServiceAdapter”，即传统数据访问方式（逻辑上的三层结构），要想系统以WCF模式运行，必须设置其值为：RDIFramework.ServiceClient

通过这样的设置，再简单部署一下，即可以SOA模式运行本程序。SOA模式运行Config.xml文件配置如下图所示。

当然了，对于SOA模式的客户端与服务端的正确配置以及绑定的方法，可以参考相关文章，在我们框架的配置文件中也进行了详细的说明。

3.1、服务端以Windows服务寄存运行

要想我们的框架以Windows服务寄存，必须部署框架的WCF服务“RDIFramework.WinService”目录包含的内容即为我们的框架以Windows服务进行寄存所必须的文件，如图7.3.1所示。图中含有两个批处理文件可以很好的帮助我们安装与卸载框架的Windows服务，他们分别是：

Install RDIFrameworkService.bat：用于安装框架的WCF服务以寄存到Windows服务上。

Uninstall RDIFrameworkService.bat：用于卸载已经安装好框架WCF服务。

如下图：RDIFramework.NET以Windows服务进行寄存所需文件所示。

双击Install RDIFrameworkService.bat文件进行服务的安装，如图7.3.2所示，输入:y，即可对服务进行安装。如下图所示：

安装成功会出现下图所示的字样。

到Windows服务管理器中，可以看到我们框架的服务已经安装成功，首次安装成功默认没有启动，就请手动启动即可，如下图所示。

对于安装成功的服务，我们也可以对他进行卸载，卸载服务使用Uninstall RDIFrameworkService.bat文件，双击此文件，输入”y”即可对已成功安装的框架服务进行卸载，如下图所示。

或者用InstallUtil.exe命令卸载框架服务也可以，如下图所示：

框架以SOA模式运行的效果如下图所示，可以看到其与传统的方式运行效果完全一样。

因为我们开启了WCF的日志功能，我们可以通过VS2010自带的“服务跟踪查看器”查看WCF的调用过程，当然建议在系统投入正常使用后，关闭WCF的日志记录功能，以免影响整个框架的效率，在此仅做测试使用，要打开VS的服务跟踪查看器，到开始菜单VS的安装菜单名下，找到“服务跟踪查看器”，即可打开，如下图所示。

通过“服务跟踪查看器”我们可以很清楚地看到我们框架是如何调用WCF服务的，整个过程都详细的进行了记录，如下图所示。对于“服务跟踪查看器”的使用方法可以参考相关文档，也可以查看其自带的帮助文件。

以上就是我们框架的分布式架构部署方案（以Windows服务为寄存宿主）。 　　

3.2、服务端以WinForm形式寄存运行

我们的框架不仅可以寄存在Windows服务程序中，还可以以WinForm形式寄存，使用方式与Windows服务寄存类似。以Winform形式寄存意思是说，服务端以窗体界面形式来启动，这种方式比较简单易懂，用户可以把启动框架服务的窗体主程序放在Windows自启动菜单，让开机时自动启动我们的框架服务。RDIFramework.NET服务端以WinForm形式寄存运行目录：Bin\FrameworkService\RDIFramework.ServiceHost.exe即可，开启后的效果如下图所示：

　　
服务端已经开启，现在运行RDIFrmework.NET客户端，效果与Windows服务方式一至。要测试我们启动的服务，我们可以使用“WCF测试客户端”来进行测试。wcftestclient.exe是一个GUI的工具用于测试WCF，只需在Visual studio command line 窗口中键入wcftestclient，就启动这个程序。如下图：

　　
可以右键“我的服务项目”选择“添加服务（A）…”来添加WCF服务，在上图中，我们输入“net.tcp://127.0.0.1:8888/RDIFramework.ServiceAdapter/UserService/mex”添加了对用户服务的测试调用。　　

3.3、服务端以IIS形式寄存运行

我们的框架不仅可以Windows服务、WinForm界面形式寄存，还可以使用IIS的Web服务形式来寄存。
　　
要以IIS方式来寄存框架的WCF服务，首先我们需要把“RDIFramework.WCFService”项目发布到IIS下，发布的方法与常规的Web发布方式一样，可以参照相关的文章，RDIFramework.WCFService项目如下图所示：

　　
发布到IIS后的效果如下图所示：

　　
在这儿需要说明的是，框架的服务发布到IIS下后，对应的应用程序池的.NET Framework版本要选择.NET Framework V4.0以上版本。如下图所示：

　　
至此，我们可以用浏览器来浏览我们发布的服务，测试发布的服务是否成功，如下图所示，我们测试StaffService服务。

　　
我们也可以用“WCF测试客户端”来测试我们发布到IIS下的WCF服务，如下图所示：

　　
以上面三种方式发布SOA服务端，来进行分布式应用的部署，都可以成功运行我们框架的客户端，用户在使用过程中，可以根据实际情况做出自己的选择。　

全新跨平台版本.NET敏捷开发框架V5.0-RDIFramework.NET震撼发布

敏捷开发框架助力企业BPM业务流程系统的开发与落地

RDIFramework.NET代码生成器全新V5.0版发布

一路走来数个年头，感谢RDIFramework.NET框架的支持者与使用者，大家可以通过下面的地址了解详情。

RDIFramework.NET官方网站：http://www.rdiframework.net/

RDIFramework.NET官方博客：http://blog.rdiframework.net/

特别说明，框架相关的技术文章请以官方网站为准，欢迎大家收藏！

RDIFramework.NET框架由海南国思软件科技有限公司专业团队长期打造、一直在更新、一直在升级，请放心使用！

欢迎关注RDIFramework.NET框架官方微信公众号（微信号：guosisoft），及时了解最新动态。