大恶人吉日嘎拉之走火入魔闭门造车之.NET疯狂架构经验分享系列之（三）商业逻辑代码部分
其实，写好几套管理软件后发现，其实大多管理软件，很多也不过是数据库设计得合理一些后
就是把数据搬来搬去而已，添加、删除、修改，然后进行一些统计分析而已。其实写代码都是
那些简单的程序Copy来Copy去，没啥需要不断突破的，代码的相似程度很大，结构体系也很
接近，处理逻辑也非常相似。
我的成长过程是：
阶段 1. 每个类都是一个个写，后来发现大多都差不多啊。
阶段 2. 注意每个类的命名，函数的先手顺序等，尽量进行统一规范，自我统一规范。
阶段 3. 对都规范化了后，新的类编写，就不从零开始了，才是Copy前面的代码，效率提高了。
阶段 4. 要求别人也按自己的方式写代码，难度就提高了，别人不愿意按你的思维方式来，代码的量太大。
阶段 5. 既然代码都大同小异，那就搞个基础类，叫BaseDao,然后继承一下这个基础类，很多代码都不用重复写了。
阶段 6. 别人就算按你的方式写了代码，发现编码很乱，不规范，不愿被别人约束，都想自由发挥，各自为战。
阶段 7. 别人还不是愿意写代码，那就弄个代码生成器来用程序来生成，这样又规范，又提高效率，又快捷了。
阶段 8. 生成好的代码经常需要改，那就干脆把自己写的代码、代码生成器产生的代码，分开来管理，这就更严谨规范了。其实凭良心来讲，做软件项目，前台做页面部分的代码，页面逻辑控制的代码，远远超过了后
台控制的代码，并不是把后台做好了，一个项目就大部分工作完成了，其实现在软件项目大部
分工作量还是在前台部分，有可能很多人有个错误的认识，做软件，好像就是写后台代码一样，
其实这部分的工作量在常规项目里估计1/3都不到，这也是我以前的一个错误认识之一，现在
我甚至认为这部分工作连1/10都不到，整个软件项目里其他事情上消耗的精力更太多了。我觉得现在谁能有采用有效的手段，大大提高前台设计及用户交互、页面逻辑判断、数据展现上
工作量和工作效率，应该是能得到大家的认可，能不能赚钱是另一回事情，能得到大家的普遍认
可也是相当苦难的事情了。这部分主要遇到的问题：
1. 分层过多，程序运行速度慢、代码量大，各个层之间的数据库交互也是一个很大问题，交互
数据的处理也是一个不少的代码量，而且这些与客户关心的功能基本上没啥任何关系，劳民伤财，
写程序是为了解决客户的实际问题，不是为了玩架构玩理念，还是务实一些比较好。
2. 数据库的表名、字段名会经常变来变去，改来改去，要有效的应对这些变化，并尽量在编译阶
段把问题及时解决。3. 代码生成器不是万能的，总需要增加几个方法等，这些代码不能混到一起去，生成器生成的
代码是不值钱的，随时随地都可以覆盖重新生成，但是你人工写的代码那一行已经远远超出10
元的价值，需要有效的得到保护及维护，代码是需要分开的。
4. 虽然现在写程序都是面向对象的，但是也不能信迷信完全相信ORM，包装得越多，灵活性越
差，性能也会下降，维护性也会降低，一些特殊的需要，为了提高性能等，SQL语句还是要支持
用户想怎么写就怎么些，谁也不是神仙，能搞出万能的高效ORM，我不信这个邪，以后应该是会
有的，现在可能是不会有的。为什么有面对那么多新技术、新架构，一直坚持自己的，不跟风的理由：
1. 我这个是2003年开始写起来的，那时候只有他们还没有出生，我不可能一直等这些知名的机构出来吧？
以后还会出来更厉害的架构，我也不是神仙，能知道什么时候能出来个啥先进的理念。2. 这是我实际工作中的点点滴滴的积累，日日夜夜维护的结晶，运行很稳定，开发效率也高，
一个陌生的架构，需要我无学习理解，需要一个时间成本，也学习过微软的架构MSPetShop4，
可能是我水平不够，我觉得那个不是我实际项目中需要的东西，那只是玩技术，里面也没多少我
可用的东西，例如权限怎么处理？组织机构管理？角色管理？用户管理？模块管理？消息管理？
工作流管理？空空的架子，那没用，我几天能架设个空架子出来，我需要有内涵，有内容，
空架子没用，还是需要啥都得靠自己干来填充好。
3. 架构还可以不断改进，学习别人的优点，取长补短，把别人的好思想理解透了，能引用到自己的
架构里来，那更需要水平，更能锻炼人的意志，经不起考验的，经不起改进的，经不起折腾的，就
本身不是什么好架构，很可能谁一大堆乱八糟的代码累加起来的。4. 对自己的架构了解透彻，优点缺点有一定的掌握，在BS，CS下的，各种考量都是相对全面的，
老外也是人，未必老外的就比我的强，我也是执着的驴子，也在积极的吸纳别人的建议，每天都在
做实际项目，一切以实际效果来说话，不纸上谈兵。5. 架构超级简单，一般人看看就知道怎么做的，菜鸟培训一周，自学1个月就可以上手了，我不太
需要高手，开发人员高兴的来，高兴的走，不依赖于技术人员，人是最靠不住的，人的脑子是活的。6. 程序边界，功能模块的边界处理，控制得很严，把某个层，某个定位推倒了，也没关系，只是
部分重构，不用全盘重构，其实架构与架构之间也没本质的天大的区别，大楼与大楼之间，人与人之
间，能有啥天大的区别，可能有，但是表面上是差不多的，一般人也不会去深入研究深层次的区别。7. 我是靠模型的积累，业务知识的积累，玩的不是技术，不是架构，我的应该更侧重的是积累，积累
做不同项目中遇到的问题的解决方法的程序上的体现，只是大家习惯了叫架构，我也就叫了这个名字，
其实我这个更侧重于软件开发项目中的业务模型、业务知识积累。虽然我们的架构是比较晚们的，但是往往实际生活中与理想状态还是差距很大，所谓的现实是残酷的
经常会遇到
A: 项目很急，对项目的质量要求也不高，那我们会直接采用 页面UI调用 - Dao(商业逻辑) - 底层数据库，
绕过什么服务层，服务接口什么神什么的，等项目上线了，觉得这个项目有重复利用的价值或者其中有些逻
辑可以进行抽取优化，那我们会把这些封装到我们的底层通用类库里进行优化。若没多大价值的随便搞搞的
项目，就采用最低的分层原则，说白了就2层就可以了，也懒得瞎搞了，累啊。B: 实在是遇到疯狂着急的小项目，甚至2层都不分，直接通过DbHelper类自己写SQL语句了，一层都
不分，编写的代码的量是最少的，见效是最快的，运行速度是最快的，这不得不承认不行，这样游击战
战术也非常适应实际项目的。C: 我们是按BS，CS系统都能适应，甚至是考虑了最复杂得多数据库，多应用系统之间的交互调用等
问题，实际当中的项目往往没那么高的复杂性要求，完全按完美架构来编写程序，层很多，代码的量很
大，等真正项目上线时，客户根本不在乎架构，更在乎是的页面效果、运行性能、业务逻辑等，架
构设计等只是程序开发人员关心而已，客户不会看到将来系统要进行扩展，与其他系统交互等，客户真的
想这么多了，我们得向客户支付咨询费了，客户比我们还专家了，可能我的老板会想到这么远吧。正规遭遇战还是要考虑战略战术，按部就班才是硬道理，大型的软件项目或者定位为产品型的软件项目，
还是严格分层，按规矩办事，才能提高整体的工作效率，单打独斗与团队作战的玩法是完全不一样的。
不去亲自感受是不会体会得到的。我做sql语句生成器的原因：
1. 字段总是变来变去。
2. 有时候拆分SQL语句，非常不方便，拼接字符串代码很乱。
3. 编译阶段往往不会发现错误。
4. 增加字段，减少字段是否可以最快捷修改代码。请看示意图图解
开发效率高的另一个表现就是，见图
例如我添加一个实体时，我需要判断这个实体是否重复了？那就用了一个很简单的方法，
this.Exists(BasePermissionTable.FieldCode, permissionEntity.Code);
函数，当然这个函数就写在 BaseDao里，继承一下，就可以，调用起来很方便。
别写那么多垃圾代码应该是好了很多，看看就明白是啥意思了，你要自己写方法
写sql语句，判断返回值等，估计要写上10行以上的代码了。Add 方式是添加方法，里面会判断是否满足要求等一些列判断，关联操作等。
AddEntity 是真正的添加实体方法，其实推敲这些函数名字啥的是非常费劲的事情。
也是无形的财富，给方法都起个合适的名字，对我们英语水平不好的人来讲很费脑子。其实不管什么管理类软件都是开发在标准数据库上，我很佩服发明论证数据库的人，
真的很伟大，其实我们做了很多管理类软件后会总结出来，数据库只有select、inserd, delete , update
语句类似，其实做开发时，我们也经常会遇到有些函数是经常被掉用来调用去，我总结了这些年的经验，
真理了一个标准的数据库操作类 DbLogic.cs。这个是比数据库访问类DbHelper封装得更多了一些。
&nbs
补充：Web开发 , ASP.Net ,
