恩，中午是发布随笔的好机会，同事各自不在工位（我开博还是比较保密的，怕伤了某些人的自尊以至于同事关系破裂。即使你看到了、你猜出我是谁了--恩说你呢，我的同事，请相信我，本文不是在说你。恩，你们看，其实我是好人）。
声明一下，本系列文章不适合追求极限效率的同学们。（您连函数调用都怕浪费效率，还讲ooad和分层干嘛。）所以如果您从事的工作若以亿万分之一毫秒计算效率的话，我真挚的恳请您忽略（放过）此文。另外本系列不会导论任何语法，语义问题（这里不是newbie教学，真的不是）。等我代码公开后如果您有兴趣与我讨论请给我留言。抱歉我还要再说一句废话，分层的思想是通用的，但是分层项目不是全部通用的，你要为你的开发组量身定做框架，如果单纯的抄袭我不敢保证可用性。
上文书，公司.net项目纷杂，毫无头绪。又不断在维护，需求变更，在这样一个恶劣的环境下怎么改善现有的情况呢？首先当然要剥离逻辑--分层了。
题外话，编码原则还是很有必要的，哪怕你是个新手。我对同事的要求是：如果你在我的麾下作战，至少你要了解并遵循开闭，单一职能和DRY。如果你不了解这三点，请你不要碰我的项目。话题扯远了，但是这确实是个问题，而且大多数情况下你很难对着一个40岁的人要求他这样那样做。毕竟人家有TM的“资历”在那么（真不明白了，年龄==资历？）。
下面继续咱们的话题。
第一版框架（这一版暂时解决了部分问题，但是总体来说还是有很多部分很失败。）起始：
按习惯首先抽出一个工具项目，将日常代码封装好塞入此项目，方便日后使用。且这个项目可以在日后开发过程中不断修正及扩展。由于我负责BS项目，主要的内容也就是Request,Response,HttpWebRequest，日志等等。将这些封装一下（当然还有很多很多其他功能）可以初步凑合使用了。但是我这里及后来的基层项目犯了一个巨大的错误，没有将项目签出，导致后来各种郁闷。
由于有些项目不会直接联库而是调用接口，所以构造了一个接口项目，这个项目中包含各种接口的调用。
仍然会有直连数据库的需求，所以还需要DBHelper项目。
在调用接口等情况下，自然会有安全隐患，所以出现了一个安全项目负责加密解密以至证书交验。
当这些基础项目搭起来之后开始进行需求项目开发，其上会有充血实体，逻辑，呈现层。
以上基本上第一版的框架的雏形就完成了。
问题接连出现了：
当开发任务进行中，我突然发现这里的配置管理是没有任何人在控制的，而且负载太多。当修改某些配置时候，即使很少的配置量，当乘以负载数量的时候，也是会有风险的。所以这时候急需一个配置管理项目。这个项目我的构思是发布一系列的XML（当然要做ACL等安全），然后做一个项目来读取。不但要读取，而且要缓存，我可不希望每次读取配置的时候都要跨网。这时候就产生了一个配置管理项目，和一个配置发布项目。并将这两个项目加到了框架中。其中配置发布项目是个虚项目，可以发布多个。
当开发项目逐渐多起来，发现接口项目会被重复调用，产生实体类，但是实体类我并没有封装在该项目中，所以在这时候亡羊补牢的修改了接口项目，添加了命名空间，填充了很多贫血实体类，并将各项目的充血实体类继承自这里。
最后一个他们历史遗留问题，异常处理，由于编码不成熟（或者脑子不好用），导致很多位置没有合理的判断，出现异常也没有被catch住。如果单纯的配置ErrorRediect虽然可以优化UE，但是同时意味着没有任何人知道什么时间，什么位置，出现了什么样的问题。所以最后放出了一个整体的异常监控项目，监控并记录异常。
至此，第一版的开发框架基本算是成型了。
随着时间推移，项目跟进，由于我没有控制好底层项目代码，以至被某些人改的面目全非。最后无奈下只好花时间来修正这些问题，并协助（？明明是代替！）某些人进行开发。
由于第一版的开发过程比较紧，也没有机会留下任何的文档。所以在这里就是大概说一说框架的项目构成及发展过程。第一版的代码也就不公布了，已经是被蹂躏的千疮百孔了，真得不好意思再拿出来显眼了。
相信高手们会发现这一版中仍然遗留问题。一些问题我将在第二版中解决掉。
好了，同事们吃饭都回来了，不方便在继续往下写了。这篇文章也就算是个铺垫把，让大家了解下第二版框架出现的历史条件，唔唔，历史事件总要有些导火索么。
PS：往后的文章中我会把我的项目设计文档部分贴上来，从框架结构到项目功能甚至到某些类。并且会逐渐公开代码。
PS2：啊啊，困了，睡觉了。晚上时间不够啊，虽然白天也不够。开发，学习，游戏……游戏不能放弃，放弃了人生就太枯燥了！
PS3：我爱编码，我小学时候的梦想就是成为程序员，虽然我现在已经远远超过这个梦想了。但是我仍然热爱这个事业！
PS4： 恩 ，放心，后边没有PS5了… 晚安各位…相信我，我说的是“晚安”，因为我要睡觉了…哈哈
