基础组件是相对于业务功能来说的，因为业务线的事务一般比较繁杂，在没有基础组件的情况下，遇到相似功能的复用大多是直接copy代码然后再粘贴修改。这样的话，类似功能存在多份代码，如果要修改一个BUG，就需要找到所有的相关代码然后再修改，费时费力，效率也不高。而且当需求功能复杂时，代码量也会随之增加，维护成本也相应增加，调试修改都变得很麻烦。所以我们需要在业务层下面抽象出一个基础组件层，该层介于基础库与业务代码之间。
我们来看看这种轮播功能:
这是很常见的内容轮播组件，在编码前我们需要找到这种组件相对变与不变的需求点，
不变的地方：
都具有一系列内容
具有自动播放功能
可以人工进行切换内容
会改变的地方：
图片大小不一样
可能某些产品的需求会有说明文字，某些没有
按钮的样子和位置不一样，某些需求没有交互按钮
不同的产品中，会有不同的动画切换效果
由此可以看出，改变的大多是UI和交互层面的，所以我们可以把本质的不变的东西直接抽象出来，再把UI层面的剃除出去就可以得到以下的设计思路：
1.列表管理功能，管理添加的内容。
2.切换功能，用以切换列表
3.播放功能，用来让内容自动轮播
4.UI渲染功能，通过配置不同的模板来得到不同的UI呈现
以上是按单一职责原则把各功能进行了拆分，抽离了基本逻辑和UI层，用图来描述大概就是这样：
其中，List列表功能管理内容，因为这种切换内容的数据结构是线形的，所以用列表描述就够了，然后其包含了“添加”、“删除”、“插入”和“清除”功能；
Switch切换功能是对列表数据进行管理，可以获取到需要的内容，包含“下一条”，“前一条”，“跳转到某一条”功能；
Player播放功能可以实现自动播放，包括“播放”和“停止”功能；
然后这里抽象出了一个View接口，并且有二个View类实现了该接口(ViewClass1和ViewClass2)，于是接口的render方法就得到了不同的实现，用以呈现不同的UI风格。
这样做有什么好处呢，
首先，我们把各功能拆分出去后，各功能间就得到了解藕，代码间的影响就小了，这样对于代码维护也方便了很多。比如发现自动播放功能有个BUG，可以直接找到Player这个类进行排查修改就行，不用再在一大坨代码里去找半天；
其次，拆分后的代码复用率得到了提高，遇到相似功能的需求时就不用直接COPY代码修改，而是获取现有的功能来使用或封装；
最后，以后有类似需求的扩展，只需要再开发实现View接口的类，配上不同的模板既可，而且不会影响到基础功能。
最后再简单总结一下，做需求开发的时候，先考虑下该功能层面的变与不变的点，然后再跟据单一职责原则进行功能拆分，分离开各独立功能以达到解藕的目的。
前端架构搭建心得
在这个公司待了半年多了，对公司的心情就不暴露了，不过有幸的是在最后的日子里面接手了一个让我尽全力去做的项目（CQM系统）。ps：原作者可能写错了，CRM(Customer Relationship Management)--客户关系管理
从第一家公司上班到现在，我也在网站这块挥霍了1年半的青春了，从后端到前端，从陌生到熟悉，渐渐的对网站的知识开始稳定的深入学习了。
我一直想自己做一个像样的东西，可是每次都没法下定决心，1是自己能力不够，2是时间上自己想偷懒，所以这次的CQM项目也算是对自己一个小小的检验吧。
ok，开始说正题，在公司我不属于项目部，由于其它原因我有机会负责这个项目的前端框架这块。
和自己想的一样，这是一个小小的OA项目，因为前端这块基本上我完全负责，所以里面的东西基本都是我自己的想法。
PS:由于有些内部资料，我不方便透露，见谅.
上面的图片是目录结构，接触过微软MVC的同学应该看出来了，没错，虽然我做前端，但是我学过C#，熟悉的就是微软的MVC，现在我用的是MVC4，当然，我用到的IDE认识微软MVC的同学也知道了吧。
首先，虽然做前端，但是我自己也需要一个简单的服务器来处理一些数据，MVC(后面的MVC皆为微软的MVC)是我一个不错的选择，因为只会这个嘛。。。
抛开其它的文件夹，主要看展开的两个.
statics和views文件夹，第一个[statics]里面装的是一些静态文件，当然ashx是放错位置了，这东西修改后需要编译，不过这东西用的不多。第二个[views]里面是页面文件。
用于我这边没有和项目组一起，在单独做，所以完全是前后端分离，只用了一些数据测试的后台编程。
我做前端的时候大体思路是：模版布局、控件组合生成、目录结构布局。
怎么理解这句话呢，我下面用一个图来说明.
这两张图是statics文件夹的说明图，因为我内部有内嵌框架，所以就有了father和son这两个文件，因为第二层内部有可能还有一个内嵌框架，end这个文件也就出来了。
下面这张图是页面布局的一个草图
从上图中可以看到，整个前端页面有3层，当然，也可以做成1层，不过因为ifrmae的框架变化很大，所以我就用3层包裹了。PS：左侧导航属于第二层.
图片3中json文件夹是存储网站需要的json数据格式的，ashx文件夹中用于测试服务器数据，plugin文件夹里面放的是js的各种框架。
zoeDylan是前端的数据处理层，无需任何其它js框架，dgg是元素交互和元素处理层，用了jq框架。
综上所述，前端静态文件和页面数据块差不多就这样了，接下来是views文件夹.
其它文件夹就不说了，主要是shared共享文件夹.
同上，son是第二层的视图公用文件，end是第三层公用的视图文件，header是头部内容，frame是所有层都需要的，主要是一些文件引用。
到这里页面的文件就ok了，接下来是逻辑思路说明.
做这个项目的时候才开始很有激情，但是1个月过去了就感觉到了吃力，因为我发现自己的能力不够啊，但是代码都写了几万行了，总要有些用嘛。
整个前端的逻辑是：后台拼合视图模版，js处理数据和显示。
页面从请求到展示的逻辑就是这样了，红线是必须加载，绿线是可能加载，最后是frmae页面中呈现，｛请求一个页面地址-模版套用-输出｝会mvc的同学应该知道mvc页面是怎么处理的，这里我就不详细说了。
ok,页面加载完成了，那数据呢？
我这里的数据是json与ajax的交互完成的，页面处理的过程中会在模版指定的div或者直接运行js上添加一个json的数据请求地址，地址会返回一个json格式的数据，然后js就开始处理，生成最后呈现在页面上的内容。
这个是dgg.js文件，用于处理数据，认真的同学会发现这个文件会创建dgg和_father两个全局函数。没错所有页面都会有这两个全局函数，dgg是包含了所有公用的数据和元素处理函数，_father是包含了最顶层框架的函数,为什么要这样做呢?
1:dgg中继承zoeDylan.js是为了统一函数，应该公司需要嘛，我就这样做了，
2:_father是为了调用顶级页面的一些事件,比如说全屏弹窗、状态显示、消息推送等。
这里主要说一说dgg.element这个函数，因为页面的数据完成基本上都是这个函数在处理。
dgg.element是一个创建页面组件的处理程序，你传入一个json格式数据，然后会根据你指定的组件名称创建一个组件，然后返回一个jq函数的组件。
下面是dgg.element函数的一些截图
dgg.element开放的方法只有两个:dgg.element.create和dgg.element.template
前者是创建组件，后者是定义组件模版的.
dgg.element的处理逻辑是:调用开发方法create-内部处理：jsonSet判断组件，提取模版tempLate中的模版样式---调用eleTemplate中对应的组件方法,用于处理组件事件---调用setAttr方法，用于处理公共元素属性---返回jq函数的组件
这里tempLate可以自定义在json的数据中，也可以用dgg.element.template配置模版和模版方法eleTemplate。下面举一个例子：
例子:生成一个组件
我要生成上面的组件，我传入的json格式就是
json中eName就是模版名称，获取json后调用dgg.element.create(json)，开始处理步骤
1:先是jsonSet处理数据,主要判断是否是多个组件
2：创建组件
3：组件事件编写,里面就是组件一系列的处理，包括组件的事件等
4：公用的组件属性处理
到这里这次笔记就结束了，由于楼主经验不足导致搭建过程中出现了N多问题，现在都还有一堆问题没解决，由于过年了放松下，年后还有加班加点做，这次的项目中自己学到的东西也不少，很容易就发现自己的不足和经验的欠缺，这次写这个笔记是对自己的第一次写前端架构的一个总结和记录，项目不怎么样，新人可以看看学点逻辑的东西，大神求指点，
224
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
