两种结构规划以及优劣

纯angular菜鸟，个人的一些想法与总结。
背景：一个数据的统计后台，左边导航栏，右边按需求的表格展示。

先说说我现在的大致结构：

• service
  
  • 左边导航的配置数据，包含title、link
  • 全局使用的其他常量数据，例如其中有一个是筛选的游戏渠道：1.网易、2.腾讯等
  • 一个loading服务，对应一个loading的view，ajax前显示，回调成功隐藏。
• config
  
  • angular_route配置文件
• directive
  
  • 自定义的左边导航下拉菜单的指令
• controller
  
  • 根据功能划分的控制器，每一个导航栏对应一个控制器
• view
  
  • 根据功能对应的模板文件，与每一个导航栏项和其控制器对应

1.根据功能划分结构

与我现在的结构一致，但是不使用requirejs或seajs的情况下，随着模块的增多，就会出现与我现在一样的尴尬问题：

虽然controller之间没有任何依赖关系…..但是看起来还是那么的蛋疼。因此我想到第二种规划结构的方式：

2.根据页面结构划分

首先，控制器不再去按照功能去划分，而是按照页面结构去划分，分为leftBar左边导航栏、rightPanel右边面板以及其子控制器formController，具体功能的数据结构，放置到一个服务中，这个服务按照用户点击的左边导航栏，去访问对应的数据接口，返回的数据直接绑定给表格控制器，直接渲染表格即可。
如果按照这种结构去划分，那么实际上控制器只有三个，数据服务层如果抽象的很高级，那么并不需要很多的文件或者对象，但是如果还是按照每一个功能建立一个数据结构，简化的工作量并没有那么多。

最后：

我们再来比较一下两种方法的优劣：

第一种情况：也是人最好理解的情况，程序不需要去处理过多结构上的逻辑处理，只需要按部就班的处理本功能区块内的逻辑，易理解，但是代码量比较大。易于修改。

第二种情况：需要大量的代码去处理结构上的逻辑，例如给左边导航栏Data对象里面加上一个getDataUrl，并封装一个ajax方法，当用户点击的时候，直接通过检索这个值去自动的ajax对应接口的数据，并渲染。这样后期增加需求的时候，你只需要去配置(左边导航Data对象)中增加一个新的属性，并赋予正确的值即可，不需要再像第一种情况一样再去定义一个控制器，写逻辑，然后引入、顺便还是更改route配置等。但是这种情况，如果没有代码本身没有一个好的结构，那么过一段时间之后很难理解，并且如果需求变动比较大，当需要修改核心代码的时候就比较痛苦了，因为其中耦合性比较强，逻辑稍微变动一下，影响很大。

因此实际情况的应用还是看项目的稳定性、以及自己的喜好了。