关于基础组件的开发与基础架构的搭建_基础组件层

作者：从前慢现在也慢 | 2024-03-21 17:10:41

踩

基础组件层

基础组件是相对于业务功能来说的，因为业务线的事务一般比较繁杂，在没有基础组件的情况下，遇到相似功能的复用大多是直接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多问题，现在都还有一堆问题没解决，由于过年了放松下，年后还有加班加点做，这次的项目中自己学到的东西也不少，很容易就发现自己的不足和经验的欠缺，这次写这个笔记是对自己的第一次写前端架构的一个总结和记录，项目不怎么样，新人可以看看学点逻辑的东西，大神求指点，

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/从前慢现在也慢/article/detail/282116