本申请涉及计算机应用技术领域，更具体地说，涉及一种以golang语言实现的mvcweb框架。
背景技术：
golang语言，又称go，是一种静态强类型、编译型、并发型，并具有垃圾回收功能的编程语言。随着golang语言的流行，涌现出了诸多以golang语言实现的mvc(modelviewcontroller，模型-视图-控制器)框架。
但这些mvc框架均以提供便捷的微服务为目的，底层设计很简单，一旦有大量的业务接入，代码会变得冗余，使得mvc框架的维护量大大增加。并且现有技术中的mvc框架与其他语言的框架并不相通，对于刚入门golang语言的开发者并不友好。
技术实现要素：
为解决上述技术问题，本申请提供了一种以golang语言实现的mvcweb框架，以解决在大量业务接入时出现的代码冗余，维护量大大增加的问题，并且提升所述以golang语言实现的mvcweb框架对刚入门golang语言的开发者的友好程度。
为实现上述技术目的，本申请实施例提供了如下技术方案：
一种以golang语言实现的mvcweb框架，包括：web服务器和框架路由；其中，
所述框架路由包括路由容器、资源模块和功能库；其中，
所述路由容器中预先绑定了所述资源模块中的静态资源、动态资源和常规资源，所述动态资源包括至少一个控制器；所述路由容器，用于接收由所述web服务器传输的用户请求，并根据所述用户请求进行第一次匹配，并根据第一次匹配结果将所述用户请求传输给所述资源模块；和用于将所述资源模块返回的响应结果返回给发送所述用户请求的客户端；
所述资源模块，用于根据第一次匹配结果对所述用户请求进行第二次匹配，并根据第二次匹配结果在所述功能库中确定与所述用户请求对应的响应结果，将所述响应结果返回给所述路由容器。
可选的，所述路由容器根据所述用户请求进行第一次匹配具体用于，当所述用户请求对应的资源为静态资源时，将所述用户请求与静态资源进行匹配；
当所述用户请求对应的资源为动态资源时，将所述用户请求与动态资源进行匹配；
当所述用户请求对应的资源为常规资源时，将所述用户请求与所述常规资源进行匹配。
可选的，所述功能库包括静态文件库、常规功能库和动态功能库。
可选的，所述控制器中的方法以契约的方式定义，并将定义的方法提取并注册到所述路由容器中；
所述资源模块根据第一次匹配结果对所述用户请求进行第二次匹配具体用于，当所述用户请求与动态资源进行匹配时，以契约反射的形式，在所述动态功能库中匹配所述控制器中的方法，并将匹配的方法的执行结果作为响应结果返回给所述路由容器；
当所述用户请求与静态资源进行匹配时，在所述静态文件库中匹配静态资源，并将匹配的静态资源作为响应结果返回给所述路由容器；
当所述用户请求与所述常规资源进行匹配时，在所述常规功能库中匹配常规资源，并将匹配的常规资源作为响应结果返回给所述路由容器。
可选的，所述资源模块在当所述用户请求与动态资源进行匹配时，以契约反射的形式，在所述动态功能库中匹配控制器中的方法具体用于，当所述用户请求与动态资源进行匹配时，将用户请求与以契约方式定义的方法进行匹配，并在所述路由容器中查找与所述用户请求匹配成功的方法。
可选的，所述资源模块还包括预先注入静态资源、动态资源或常规资源中的插件资源。
可选的，所述静态资源包括脚本javascript文件、样式css文件、图片、音频字体和视频字体；
所述动态资源包括一个用于处理逻辑请求的控制器；
所述常规资源包括自定义的http错误、异常、服务错误功能。
可选的，所述web服务器用于接收客户端发送的用户请求，并将接收的用户请求传输给所述框架路由，和用于将所述资源模块返回的响应结果返回给所述客户端。
从上述技术方案可以看出，本申请实施例提供了一种以golang语言实现的mvcweb框架，该以golang语言实现的mvcweb框架包括web服务器和框架路由，所述框架路由包括路由容器、资源模块和功能库，所述路由容器中预先绑定了所述资源模块中的静态资源，用于接收由所述web服务器传输的用户请求，并根据所述用户请求进行第一次匹配，并根据第一次匹配结果将所述用户请求传输给所述资源模块；和用于将所述资源模块返回的响应结果返回给发送所述用户请求的客户端；所述资源模块，用于根据第一次匹配结果对所述用户请求进行第二次匹配，并根据第二次匹配结果在所述功能库中确定与所述用户请求对应的响应结果，将所述响应结果返回给所述路由容器。即通过所述路由容器、资源模块和功能库的配合实现对原生底层框架的封装扩展，进而实现了接口通用方式调用的服务及以前端页面形式提供服务的方案，避免了在大量的业务接入时，导致的代码冗余和维护量增加的问题；并且所述以golang语言实现的mvcweb框架与其他语言的mvc框架相通，可使刚转入golang语言的开发者能够快速上手，提升对于刚入门golang语言的开发者的友好度，降低学习成本。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
图1为本申请的一个实施例提供的一种以golang语言实现的mvcweb框架的结构示意图；
图2为本申请的一个实施例提供的一种框架路由的结构示意图；
图3为本申请的一个实施例提供的一种框架路由的工作流程示意图；
图4为本申请的另一个实施例提供的一种框架路由的工作流程示意图；
图5为本申请的另一个实施例提供的一种框架路由的结构示意图；
图6为本申请的又一个实施例提供的一种框架路由的工作流程示意图；
图7为本申请的另一个实施例提供的一种以golang语言实现的mvcweb框架的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
本申请实施例提供了一种以golang语言实现的mvcweb框架，如图1、图2和图3所示，包括：
web服务器10和框架路由20；其中，
所述框架路由20包括路由容器21、资源模块22和功能库23；其中，
所述路由容器21中预先绑定了所述资源模块22中的静态资源、动态资源和常规资源，所述动态资源包括至少一个控制器；所述路由容器21，用于接收由所述web服务器10传输的用户请求，并根据所述用户请求进行第一次匹配，并根据第一次匹配结果将所述用户请求传输给所述资源模块22；和用于将所述资源模块22返回的响应结果返回给发送所述用户请求的客户端；
所述资源模块22，用于根据第一次匹配结果对所述用户请求进行第二次匹配，并根据第二次匹配结果在所述功能库23中确定与所述用户请求对应的响应结果，将所述响应结果返回给所述路由容器21。
图1为所述以golang语言实现的mvcweb框架的结构示意图，图2为所述框架路由20的结构示意图，图3为所述框架路由20的工作流程示意图。
可选的，所述静态资源包括脚本javascript文件、样式css(cascadingstylesheets，样式层叠表)文件、图片、音频字体和视频字体；
所述动态资源包括至少一个用于处理逻辑请求的控制器；
所述常规资源包括自定义的http错误、异常、服务错误功能。
所述静态资源、动态资源和常规资源的使用根据用户请求自由搭配，例如当应用所述以golang语言实现的mvcweb框架构建接口(api)服务时，可以完全脱离静态资源；当利用所述以golang语言实现的mvcweb框架构建纯静态页面服务时，也可完全脱离动态资源。另外，所述常规资源是为了丰富服务的功能提供便利性以及自定义性，在应用过程中的调用根据需求而定，并非强制要求。
在本实施例中，所述以golang语言实现的mvcweb框架通过所述路由容器、资源模块22和功能库23的配合实现对原生底层框架的封装扩展，进而实现了接口通用方式调用的服务及以前端页面形式提供服务的方案，避免了在大量的业务接入时，导致的代码冗余和维护量增加的问题；并且所述以golang语言实现的mvcweb框架与其他语言的mvc框架相通，可使刚转入golang语言的开发者能够快速上手，提升对于刚入门golang语言的开发者的友好度，降低学习成本。
具体地，参考图4，所述路由容器21根据所述用户请求进行第一次匹配具体用于，当所述用户请求对应的资源为静态资源时，将所述用户请求与静态资源进行匹配；
当所述用户请求对应的资源为动态资源时，将所述用户请求与动态资源进行匹配；
当所述用户请求对应的资源为常规资源时，将所述用户请求与所述常规资源进行匹配。
参考图5，所述功能库23包括静态文件库231、常规功能库232和动态功能库233。
相应的，所述控制器中的方法以契约的方式定义，并将定义的方法提取并注册到所述路由容器21中；
所述资源模块22根据第一次匹配结果对所述用户请求进行第二次匹配具体用于，当所述用户请求与动态资源进行匹配时，以契约反射的形式，在所述动态功能库233中匹配所述控制器中的方法，并将匹配的方法的执行结果作为响应结果返回给所述路由容器21；
当所述用户请求与静态资源进行匹配时，在所述静态文件库231中匹配静态资源，并将匹配的静态资源作为响应结果返回给所述路由容器21；
当所述用户请求与所述常规资源进行匹配时，在所述常规功能库232中匹配常规资源，并将匹配的常规资源作为响应结果返回给所述路由容器21。
具体地，所述资源模块22在当所述用户请求与动态资源进行匹配时，以契约反射的形式，在所述动态功能库233中匹配控制器中的方法具体用于，当所述用户请求与动态资源进行匹配时，将用户请求与以契约方式定义的方法进行匹配，并在所述路由容器21中查找与所述用户请求匹配成功的方法。
在程序注册控制器(mvc框架中的ctronller层)，由于一个控制器中可以有非常多的方法(函数)，如果通过代码一行一行的去匹配这些方法，不但工作量大，维护麻烦，还有可能会出错。
在本实施例中，采用了契约反射的匹配方式匹配精细的用户请求以避免上述问题。契约反射的匹配方式去除了手工添加代码的繁琐，不仅大量的精简了代码量，还是的代码更加规范且易于维护。
在利用契约反射的匹配方式时，大致需要做以下工作：
首先在收集web服务器10可以提供的用户请求的几种方式(例如get请求、post请求、put请求和delete请求等)；
然后在控制器中用契约的形式定义方法(比如get_fun1、post_fun1等)；
通过反射程序代码将控制器中定义的方法提取出来，注册到路由容器21中；
最后即可对用户请求进行匹配，在路由容器21中查找与用户请求对应的方法，执行找到的方法并返回结果。
在上述实施例的基础上，在本申请的一个可选实施例中，如图6所示，所述资源模块22还包括预先注入静态资源、动态资源或常规资源中的插件资源。
在本实施例中，插件资源的注入属于可选过程，该环节可以高度定制个性化，属于非必须过程。
由于我们的插件资源是在可以在用户请求过程中提前做业务逻辑控制，所以我们只用集中处理我们的插件管理功能，而不用处处维护修改其他地方的逻辑代码。简之，通过插件的处理，可以让我们的程序维护起来更简单，业务逻辑相互分离不影响，也可以个性化实现更复杂的需求。
在实际使用过程中，比如我们写一个访问日志记录的功能，我们需要查看我拍摄的照片、视频被访问了多少次。那么我们的这个插件资源就可以定义为“媒体浏览量”插件。由于我们的正常业务资源分为三种形式，而我们只需要对照片、视频(静态资源)做监测，此时就可以在插件资源中写好静态资源的路由规则，一但匹配，则执行插件中的业务逻辑。(注：用户验证功能在业界也常做插件(中间件)管理)。
在上述实施例的基础上，在本申请的另一个可选实施例中，如图7所示，所述web服务器10用于接收客户端发送的用户请求，并将接收的用户请求传输给所述框架路由20，和用于将所述资源模块22返回的响应结果返回给所述客户端。
综上所述，本申请实施例提供了一种以golang语言实现的mvcweb框架，该以golang语言实现的mvcweb框架包括web服务器10和框架路由20，所述框架路由20包括路由容器21、资源模块22和功能库23，所述路由容器21中预先绑定了所述资源模块22中的静态资源，用于接收由所述web服务器10传输的用户请求，并根据所述用户请求进行第一次匹配，并根据第一次匹配结果将所述用户请求传输给所述资源模块22；和用于将所述资源模块22返回的响应结果返回给发送所述用户请求的客户端；所述资源模块22，用于根据第一次匹配结果对所述用户请求进行第二次匹配，并根据第二次匹配结果在所述功能库23中确定与所述用户请求对应的响应结果，将所述响应结果返回给所述路由容器21。即通过所述路由容器、资源模块22和功能库23的配合实现对原生底层框架的封装扩展，进而实现了接口通用方式调用的服务及以前端页面形式提供服务的方案，避免了在大量的业务接入时，导致的代码冗余和维护量增加的问题；并且所述以golang语言实现的mvcweb框架与其他语言的mvc框架相通，可使刚转入golang语言的开发者能够快速上手，提升对于刚入门golang语言的开发者的友好度，降低学习成本。
本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。
对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。