一步一步搭架子（完结篇）

如果您是初次阅读这个系列，请先去《Index & Writing Plan》查找并阅读“架构设计系列”的前两篇文章，顺序阅读会使您有更好的阅读体验

强烈推荐配合源代码阅读本文：点击此处下载（可以直接运行，会在本地自动生成数据库）

 

正文开始

上一篇我们写完了Service，剩下Controller和View，但是这两个都是没什么可说的了：

Controller其实就是接收Service处理过的数据，并且呈现给页面；因为业务逻辑已经在Service中处理过了，所以Controller无非就是将数据稍微修改一下，比如说日期的显示方式，2012/11/15，还是2012-11-15

而View，也没什么和构架相关的东西，一笔带过

 

我这篇文章真正想写的是我和我同事的讨论

同事提出了一个想法：按照之前的架构，每个学校我都要去写一套Controller与View，而其实这里面并不是所有页面都有差异的。比如说TeacherList页面，虽然不同的学校有不同的差异字段，但是List页面不一定会将差异字段显示出来。比如说现在A、B、C三所学校TeacherList要显示的字段是一样的，那么我还去写3套Controller和View，是不是显得很傻

根据分析老系统，大概有30%以上的页面是没有差异的

他也提出了他的构架图，其中Controller和View是否相同的判断可以通过.NET MVC强大的路由功能来精彩的实现，有兴趣的同学可以自行搜索相关文章

 

这个构架的大体思路就是：什么不同，我就重写什么；有且只在需要的时候重写

 

看起来很美妙，整个构架相当精炼，没有多余的地方，但是真的是无懈可击的么？

以下是我和他的Skype的聊天记录：

我：有3种层次：

         1、业务逻辑不一样，重写Service

         2、页面逻辑不一样，调整Controller

         3、页面不一样，重写页面

         可以这样整理吧

他：我想的是这样

         但不知道实际开发时会不会搞乱。

我：我觉得还是弄简单点好吧

         我自己都觉得理解起来有些困难

他：不知道怎样才能简单。

         route 重定位这里本来就比较复杂的。

         调整Action 很容易搞乱。

我：我再想想

他：稍微多写点东西，项目结构简单。这样应该好一点

我：是啊，简单的往往是最好的

         我听说过一种说法，说是你把系统构架图画出来

         如果系统构架图漂亮，那么就是一个好系统

他：ACTION 配置多会比较麻烦

         尽量少点像刚才的那种 VIEW 和Controller循环重定位的东西。

我：要不还是每个城市写一套Controller和View算了

         T4模板弄好的话，这个也挺快的

他：这个再想想，到时候去会议室讨论吧。

 

是的，我们都认为这个构架的最大弱点在于复杂

连设计构架的人都会被弄得思维混乱，那么几乎可以确定这个构架对于使用者来说，相当的不友好，虽然减少了代码量，但是增加了逻辑负担

 

最后我们讨论的结构是：维持原有构架

因为权衡之后，觉得依靠T4模板，写Controller和View并不是多重的负担

 

就此，整个项目的构架都这样定下来了，准备应用到生产环境中

就此搁笔

 

PS：VS212真心好用