程序设计之MVC工作分配，关于客户端开发之我鉴（三）

上回书讲到了我们把MVC的结构整理了一下，大概对程序有一个初步的整体认识。那我们现在开始从开发的角度看看我们的程序的文件结构应该怎么组织一下可以更方便于我们开发。可以也按照MVC的思想贯彻下去，分别把MVC三个家伙一人给一个大的文件夹。哪个放哪里我想大家都很清楚哈，这个要是都不清楚那你确实应该补补课了。对了有的时候我们不免会用到一些第三方库，我也会给他们分出一个大的文件夹。

再详细的说一说一些方便开发的小类。首先，我喜欢给程序单独一个全局的宏定义的文件放一些全局的宏定义，这样不只自己修改查看不用到每一个类文件去查找修改，而且大家都有一这么一个约定好的地方就不容易产生一些不必要的麻烦。然后，还有一个类主要负责比如处理程序中比较杂碎的大家都经常用到的工作，像是处理时间格式，生成mac地址如此云云的一些功能让全局都可以很方便的用到也省得大家去做这些不必要的工作。同时温馨提示可以把这个类放到程序的代理中写一个宏定义。（PS：这个谁用谁知道）这两个都是基于多人协作产生的，我也强烈建议如果你和你的团队的技术都相差不多，而且都非常有士气最好是将MVC三个分开编写这样对程序的封装和代码复用相当有积极的影响。

上面的龙套都说完了，现在主角来了，M这个家伙是负责向C传输数据的并且让C对于数据不闻不问毫不关心。他自己的不只要关心数据还要负责检查数据的正确性，一定要保证按照约定传送数据，这里我唠叨一下两个接口传输的数据最好是使用copy传输，这样防止一些由于低级的失误产生的意外（PS：有点意外怀孕的感觉）

V这个家伙说起来就比较光鲜亮丽了，和M这个苦力不一样，他无时不刻的不和用户打着交道，人们也只能看到他，喜欢看他，和他做着游戏什么的。要是他有点残疾什么大家一眼就看出来了。不过正是因为他有这样的位置，所以M和C都要对他有一定的影响要保证他的正确性。这个我要提醒广大的抠腚先生们一定不要轻易放过你们的UI，一定要仔仔细细的推敲研究，不要让我们自己去推敲决定，这样虽然你放松了对他们的要求让他们舒舒服服的完成工作，可是接下来你所有的猜测和判断都是要自己负责任的噢。（PS：私下里关系好归关系好，工作可是不能马虎的）

最后一个就是C了，他起到了承上启下的作用，重要性也可想而知。他享受着M辛辛苦苦的劳动，对光想靓丽的C指手画脚。UED主要负责他的逻辑问好，一定要问好一些深层次的逻辑异常是很复杂的，也关系到了你程序和类的设计，一旦你没有问清楚，很可能相当大一部分的代码都是要牺牲的哦。（PS：辛辛苦苦的都白扣了，多不甘心）

这回就先白话到这吧，下回我想好好的说一下他们其中一个的七七八八及一众小弟。

写的不好或者有什么不对，希望大家可以不吝惜自己的力气告诉我。