频道栏目
首页 > 程序开发 > Web开发 > ASP.Net > 正文
大恶人吉日嘎拉之走火入魔闭门造车之.NET疯狂架构经验分享系列之(三)商业逻辑代码部分
2010-12-01 15:31:47           
收藏   我要投稿

其实,写好几套管理软件后发现,其实大多管理软件,很多也不过是数据库设计得合理一些后
就是把数据搬来搬去而已,添加、删除、修改,然后进行一些统计分析而已。其实写代码都是
那些简单的程序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

点击复制链接 与好友分享!回本站首页
上一篇:大恶人吉日嘎拉之走火入魔闭门造车之.NET疯狂架构经验分享系列之(二)后台服务代码部分
下一篇:漫谈.NET开发中的字符串编码
相关文章
图文推荐
点击排行

关于我们 | 联系我们 | 广告服务 | 投资合作 | 版权申明 | 在线帮助 | 网站地图 | 作品发布 | Vip技术培训 | 举报中心

版权所有: 红黑联盟--致力于做实用的IT技术学习网站