大恶人吉日嘎拉之走火入魔闭门造车之.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. 对自己的架构了解透彻，优点缺点有一定的掌握，在B\S，C\S下的，各种考量都是相对全面的，
老外也是人，未必老外的就比我的强，我也是执着的驴子，也在积极的吸纳别人的建议，每天都在
做实际项目，一切以实际效果来说话，不纸上谈兵。

5. 架构超级简单，一般人看看就知道怎么做的，菜鸟培训一周，自学1个月就可以上手了，我不太
需要高手，开发人员高兴的来，高兴的走，不依赖于技术人员，人是最靠不住的，人的脑子是活的。

6. 程序边界，功能模块的边界处理，控制得很严，把某个层，某个定位推倒了，也没关系，只是
部分重构，不用全盘重构，其实架构与架构之间也没本质的天大的区别，大楼与大楼之间，人与人之
间，能有啥天大的区别，可能有，但是表面上是差不多的，一般人也不会去深入研究深层次的区别。

7. 我是靠模型的积累，业务知识的积累，玩的不是技术，不是架构，我的应该更侧重的是积累，积累
做不同项目中遇到的问题的解决方法的程序上的体现，只是大家习惯了叫架构，我也就叫了这个名字，
其实我这个更侧重于软件开发项目中的业务模型、业务知识积累。

 

虽然我们的架构是比较晚们的，但是往往实际生活中与理想状态还是差距很大，所谓的现实是残酷的
经常会遇到
A: 项目很急，对项目的质量要求也不高，那我们会直接采用 页面UI调用 - Dao(商业逻辑) - 底层数据库，
绕过什么服务层，服务接口什么神什么的，等项目上线了，觉得这个项目有重复利用的价值或者其中有些逻
辑可以进行抽取优化，那我们会把这些封装到我们的底层通用类库里进行优化。若没多大价值的随便搞搞的
项目，就采用最低的分层原则，说白了就2层就可以了，也懒得瞎搞了，累啊。

B: 实在是遇到疯狂着急的小项目，甚至2层都不分，直接通过DbHelper类自己写SQL语句了，一层都
不分，编写的代码的量是最少的，见效是最快的，运行速度是最快的，这不得不承认不行，这样游击战
战术也非常适应实际项目的。

C: 我们是按B\S，C\S系统都能适应，甚至是考虑了最复杂得多数据库，多应用系统之间的交互调用等
问题，实际当中的项目往往没那么高的复杂性要求，完全按完美架构来编写程序，层很多，代码的量很
大，等真正项目上线时，客户根本不在乎架构，更在乎是的页面效果、运行性能、业务逻辑等，架
构设计等只是程序开发人员关心而已，客户不会看到将来系统要进行扩展，与其他系统交互等，客户真的
想这么多了，我们得向客户支付咨询费了，客户比我们还专家了，可能我的老板会想到这么远吧。

正规遭遇战还是要考虑战略战术，按部就班才是硬道理，大型的软件项目或者定位为产品型的软件项目，
还是严格分层，按规矩办事，才能提高整体的工作效率，单打独斗与团队作战的玩法是完全不一样的。
不去亲自感受是不会体会得到的。

我做sql语句生成器的原因：
1. 字段总是变来变去。
2. 有时候拆分SQL语句，非常不方便，拼接字符串代码很乱。
3. 编译阶段往往不会发现错误。
4. 增加字段，减少字段是否可以最快捷修改代码。

请看示意图图解

开发效率高的另一个表现就是，见图
 

例如我添加一个实体时，我需要判断这个实体是否重复了？那就用了一个很简单的方法，
this.Exists(BasePermissionTable.FieldCode, permissionEntity.Code);
函数，当然这个函数就写在 BaseDao里，继承一下，就可以，调用起来很方便。
别写那么多垃圾代码应该是好了很多，看看就明白是啥意思了，你要自己写方法
写sql语句，判断返回值等，估计要写上10行以上的代码了。

Add 方式是添加方法，里面会判断是否满足要求等一些列判断，关联操作等。
AddEntity 是真正的添加实体方法，其实推敲这些函数名字啥的是非常费劲的事情。
也是无形的财富，给方法都起个合适的名字，对我们英语水平不好的人来讲很费脑子。

其实不管什么管理类软件都是开发在标准数据库上，我很佩服发明论证数据库的人，
真的很伟大，其实我们做了很多管理类软件后会总结出来，数据库只有select、inserd, delete , update
语句类似，其实做开发时，我们也经常会遇到有些函数是经常被掉用来调用去，我总结了这些年的经验，
真理了一个标准的数据库操作类 DbLogic.cs。这个是比数据库访问类DbHelper封装得更多了一些。

以上图片不光看代码多，其实总共也没几个函数，只是为了调用方便，写了很多重载方法，稍微自己看几眼，很容易就知道怎么用了。
说得在白话一些，就是把常用的函数，都给提供出来了。

参数 dbHelper，主要是为了一些列操作，都是在同一个数据库连接上进行，不频繁Open、Close数据库，
并且为了灵活控制数据库事务为目的，提高数据库效率、增强灵活的并发控制产生的。

这些函数，在其他各个管理软件开发中，都会用到，而且也不是很多，很实用，新来的同事，稍微培训一下，也能看懂，
用的时间长了，函数也会越来越丰富，越来越稳定，越来越成熟，当然就会变得越来越经得起考验了。

就算你是讨厌用我的架构，这些函数用用也很爽的，代码写得也清爽，一看就明白，自己写出来整理好也很辛苦，别人的
若直接能给你，不是很省事嘛？而且大家都容易理解，一个团队里也好传播开来，会适当的提高代码的可阅读性及质量。

下面的图是，SQLBuilder.cs的程序截图，这个也可以当是没有，一个小工具，用也行，不用也行，我个人感觉
这个还是很有优点，就把截图放上来，因为实现这个也很简单，总共也没多少行代码，性能上也没啥影响。
 

 

其实我们是谁都不服谁的
我们国内的开发人员呢都有“让我做什么功能，只要你提出来，我什么都能弄出来，他
那点儿玩意儿我也能实现，没啥的”，给点儿时间是不是可以把原子弹也造出来？那为啥
不是你早就弄出来一个了？其实这个是个谬论，会误导很多人，做一个东西，甚至写个函数，
都需要检查代码质量、思路是非正确、分工定位是否合理、是否进行了性能测试?是否进行了
功能测试？是否稳定运行了一段时间？是不是已经是写得最高效率了？都需要一个过程，
需要时间，都需要精力，那就是代价。
虽然过程对于个人来讲是提高，对于公司来讲是成本，我是不需要开发，不需要学习，
我手上马上就有，你今天要？我明天就可以提供给你，这就是我比别人的最大的优点，
而比的不是我技术有多高深有多先进，哪里想怎么维护都可以维护，这只是按常规开发
人员的常规思路积累稳定下来的开发成果。
看起来简单的东西，未必真的是那么简单的，我们看得见摸得着的汽车来比喻，我们国家
也造不过老外，在简单一点儿，连个军刀，也搞不过瑞士嘛，让你搞个刀子出来，不知道
会丑陋到什么程度，这是实话的讲。

 

真的非要我说出，我的优点有如下：
01. 我这个不是空架子，有内涵，大多开发框架只是空空的。
02. 与我的框架还有配套的完整的权限体系。
03. 我有配套的代码生成器。
04. 我有比较成熟的基础类，上千行的代码可以重复利用，提高效率。
05. 我有比较成熟的，数据库常用的操作方法，用起来效率很高。
06. 学习成本低，说实话我学过Enterprise library，甚至还买了一本书，我是没能学会，可能我太弱智了，没人带，没人教，想掌握得很熟练，也不容易。
07. 我有成熟的B/S,C/S开发样列，不是倾向于某个，甚至都有标准的例子程序，
为大规模生产奠定了基础。
08. 我这个短小精悍，效率有希望能提高，例如Enterprise library、ibatis 有用没用的东西，应该是比我的更多很多。
09. 使用灵活，想怎么写程序就怎么写程序，处了分层几乎没其他约束，
那些想写个SQL语句不是不可以，你不想不规范的来，怎么写都可以。
10. 都是组件化的，互相之间的关联性若一些，数据库访问类等都可以单独拎出来用，数据库访问操作类等，都可以是跟其他无关的。你不用我的架构，至少这些还有重复利用的价值。
11. 我这个灵活性强，想怎么修改就怎么修改，想运行什么SQL语句就运行什么SQL语句，iBATIS里想运行一个动态的SQL语句都难啊。
12. 虽然不是很排斥iBATIS，但是里面的SQL语句太难搞了，这个做过几个项目的，都应该会有些感触，特别是复杂的SQL语句。
13. 类似iBATIS等架构里，控制并发、控制事务，几乎是无从插手啊，我想普通人是不太容易搞定的。
14. [狡辩] 向下兼容，不用非要需要.NET3.0, .NET3.5运行环境，对运行环境的要求很高，也不是开玩笑的折腾啊，有的电脑上装都装不上，卸载也卸不了的。

 

能了解学习需要一个水平，
能用嘴巴讲出来需要一个水平，
能形成自己的思想需要一个水平， 
能用文字描述出来更需要一个水平，
有勇气贴出来，敢共享自己的思想也是更加需要水平，
我是希望那些站着说话不腰疼的家伙们，只拍砖头不拍理由的，也写写看，写出来是什么样子，让我们心服口服。
当我工作的第3-4年，我也层感觉过，天下就我最厉害，哈哈，现在想想，自己是啥呀？普通老百姓一个而已。

欢迎大家提出宝贵的建议，多拍砖并拍出理由。

 

 

 

我写程序的灵感就像是如下图片一样

 

 

 

导读：

大恶人吉日嘎拉之走火入魔闭门造车之.NET疯狂架构经验分享系列之（一）后台控制逻辑代码部分
http://www.cnblogs.com/jirigala/archive/2009/06/16/1503913.html

大恶人吉日嘎拉之走火入魔闭门造车之.NET疯狂架构经验分享系列之（二）后台服务代码部分
http://www.cnblogs.com/jirigala/archive/2009/06/16/1504515.html

大恶人吉日嘎拉之走火入魔闭门造车之.NET疯狂架构经验分享系列之（三）商业逻辑代码部分
http://www.cnblogs.com/jirigala/archive/2009/06/17/1505253.html

大恶人吉日嘎拉之走火入魔闭门造车之.NET疯狂架构经验分享系列之（四）高效的后台权限判断处理
http://www.cnblogs.com/jirigala/archive/2009/06/22/1508511.html