web MVC

昨天还在整理我们的框架文档和网页，再过几天就可以和大家见面了。

整理到web页面，觉得有一篇web mvc的整理的还算不错，提前给大家分享一下：

概述

这个章节很重要！

随着体验经济的到来，现在的web应用对客户体验交互操作要求越来越高。这样，客户端的代码越来越多，逻辑越来越复杂，再也不是之前的简单完成功能即可的“网站”应用了。

这样，客户端脚本的代码由结构化组织，逐步转变到设计模式组织。即越来越多的后端优秀的设计模式框架，应用到前端中。MVC是一个非常优秀的设计思路。BreezeJS是一个模拟后端的实现模式，自然可以很方便的引用其优秀的设计思路。

本章节重点介绍了在前端如何进一步使用webmvc分解应用方案。

如下图，就是我们提供的最佳实践方案的文件组织方式：

这个空包可以在这里下载。

servicegadget

在前端，我们把独立的和页面无关，业务相关的逻辑处理，全部放到servicegadget中。

在servicegadget中，一定要将和页面相关的交互操作逻辑从这里剥离出去，因为在页面上，我们或许会有很多不同的页面模板，这些不同的页面模的交互肯定会不同，但是业务代码是基本固定的。

因此，我们很有必要将业务代码独立出来。这样即便在不同的显示终端，如微信，pc页面等都可以使用。

举个例子，比如和订单相关的操作，我们可能会统一封装到order.js中，而很多前端页面，比如首页可能会有订单操作，列表页可能有订单操作，所以在页面操作会引用或者继承的方式去复用order.js里面的内容。

而这个order.js就会放置到servicegadget/order/order.js下面。

page目录

页面是复杂的，要兼顾美观，交互；而且还会有多个终端的情况，在不同的页面，面对不同的终端。

所以，我们将业务层面的逻辑，从这里抽离出去，这里只放置和页面，交互相关的逻辑代码。

因为对于一个页面来说，首先考虑的可能会面对多种不同风格模板，所以page下面的直接第一级目录，是模板风格名称，比如sytle1，等等。

pagegadget

style下面自然就会放置页面，gadget，以及gadget的resource等文件，而页面又包含了css，以及共用的头部尾部等文件。通用的头部尾部文件我们统一放到comm目录下。

而这个页面的所有交互，都会有与之配套的gadget，在page目录下的gadget我们称之为pagegadget。是和业务无关页面相关的操作，专门用于存放交互相关代码。

resource

gadget我们有对应视图资源，那么视图实际和页面展示相关的，我们就独立的放置到resource目录下，我们将整个网站一个独立风格的所有gadget的视图声明都放到一个文件下，就是resource.js中，在这里面去声明某个gadget对应的视图资源是什么。

显然，具体的某个gadget会有多个不同的视图资源，就是我们说的tpl文件，这些文件将以独立目录存放到resource目录下。

版权声明：本文为博主原创文章，未经博主允许不得转载。