大恶人吉日嘎拉之走火入魔闭门造车之.NET疯狂架构经验分享系列之(二)后台服务代码部分
程序写太长了,大家看着也累,我也写着也很辛苦,接下来,还是写得简短一些,尽量多一些截图,少一些文字吧。
同样是,欢迎指点批评的同学,我虚心学习提高,改改以往的高姿态。
架设软件系统就像大家看饭店厨师炒菜一样,一看就懂觉得太简单了,但是自己炒一盘菜就知道是啥样子,是不是
跟厨师炒出来的一样的,看看别人的很简单,自己动手做才能真正体会了,我们看操作系统也没啥的呀?对不。我的后台服务代码部分,请看截图及介绍。
当然没必要要求每个人都必须这么写代码,这样写代码的代价也是很高的,当然我们是采用代码生成器来产生这些代码,效率会比较高一些。本来是想热情洋溢的写写以上抓图的详细解释,看博客园里的第一条评论后,一点儿胃口也没了,懒得写了。
主要是以上图片太大了,缩小后有些变形,想看得舒服一些,另存打开就可以了,也不是字体的原因。
当然你的项目没有对异常处理的严格要求,
对数据库处理的严格要求,
也没并发处理的严格要求
也没必要非要写得这么严谨,因为写得严谨也有个投入产出比的,想快速见效的项目,随便搞搞就可以了,
想做为一个长期的投资,在N个项目里反复使用的标杆组件,那是值得精心维护,因为重复利用的价值太高了。我们虽然跟老外比,比老外聪明,但是都没聪明在正事上,耍小聪明的多,大智慧上干不过人家,这也是
为什么我们国家软件行业这么弱的原因之一,我们又有我们致命的中国特色,差不多就可以,稀里糊涂就
可以,导致我们做不好高质量的东西的更本原因之一,我们还有个传统美德,就是短斤少两,偷工减料的
严重,能省事就省事,能偷懒就偷懒,所以这也是导致我们经常造出假冒伪劣商品的原因之一。好产品的
工序,工艺,投入是省不了的。很早的时候,德国人的产品在欧洲被取笑为笨拙的代名词,但是德国人做事严谨,产品不断改进,最后还
是做出来让大家非常满意的产品,日本很固执吧,也造出了很多好产品,车子、电子产品等,我们不能光
说人家日本人固执。我也做过美国佬的项目,人家项目的范围定位非常明确,就要那么几个功能,不是像我们国内做软件一样
需要很多神奇的功能,无边易做图,思路混乱,美国老虽然功能明确,但是对质量的要求也很高很高,很精
细,我们跟别人的差距还是很明显的,差距啥?最有差距的就是思维、思想、理念。
我说说我的程序的思想:01.版权声明,没这个就像宝马车没贴标志,看着很别扭。
就像人有个名、公司有个标志,这是品牌,例如同样一个车子帖上宝马的标志和夏利的标志,效果会是啥样?
品牌的作用还是很强大的,另外这也是版权的声明啊,我们可能全用D版,也没多少知识产权的概念,所以大
多数人都不重视这个,很可能这个观念是错误的,我看很多老外的开源,大多都有版权声明什么的,看着也很
舒服,觉得有这个很好,你懒得写这些,那你可以做个模板文件,就是用笨方法,复制粘贴,也没啥,干活累
了,就当是娱乐,贴上去好了,我从来没感觉到这是累赘。02.引用了自己的包,不是微软公司的标准包,这里分开写。
我自己是比较反感,using一大堆的情况,甚至是喜欢把using的顺序都进行排序,按引用先后逻辑顺序或者
命名空间的命名顺序,把这些都排好,哪些是用了系统默认的命名空间,哪些是我自己引用的,看着清清楚
楚的,这个文件里,那些命名空间是没必要引用的,都会剔除掉,尽量不多一样代码,也不少一行代码。闲着
也没事干,就摆弄摆弄这些,争取让别人挑不出错来为止。03.一些比较重要的修改记录,以后还可以看看折腾过几次,都有过什么改进变化,算是成长故事。
一个程序经常需要维护很多年,技术不断在进步,程序员也是,看到别人写得好,就学习,技术更先进了,
与需要与时俱进,刚开始写程序没思想,能达到功能就可以了,例如能有个车子,能跑就可以了,就算是有
个奥拓,也很开心啊,当然有车了后,你又想更好的车子,想奔驰宝马,你会有很多新的思想,我也是,经
常会追求更高的境界,想尽一切方法提高自己的技能,这就导致有些程序会不断改进,反复改进,需要投入
很多成本,多年过去后,你可以看看,你曾经都干了啥?都走过什么样的路,到底花了多少代价成本,好心
里有个数,个人是如此,更何况一个公司呢?公司更需要记录这些修改历史、投入的成本,若是很多人修改
了代码,改好了没关系,改错了呢?还需要找责任人啊?犯罪了,还需要留下罪证吧,哈哈,当然也不是绝
对的。04.实现的标准接口及一些远程调用的继承,这样这个服务才可以远程调用。
我就来个白话讲接口的作用
A:到底提供那些服务?你的系统有那些服务?服务的个数也计算软件项目的工作量的一个依据。
B:每个服务里又有那些方法提供给别人调用,先手顺序是什么?服务中的方法个数也是计算软件软件项目的工作量的一个依据。
C:你到底需要实现那些服务接口,我们先可以把接口确定下来,然后前台可以分给一个人编写,后台分给另一个人写,他们有规范的接口来实现统一。若你的程序里很少看到接口,那你可以注意一下了,接口在某种程度上表明了你对整个项目的把握程度及
整体的控制,说白了,没接口的软件程序可以看做是在瞎搞不专业,可能这么说严重了一些啊,从我自身
的总结来讲,这么说一个程序员,也不太过分,所以你还没重视接口,那从现在开始就彻底重视接口绝对
没错的。05.设计模式中的单实例,是为了提高运行性能等时用。
这个我不用多说,每次在内存里new一个类的实例,还是蛮需要消耗资源的,若不是有很严格的并发需要,
也没有很严格的事务控制,单实例的确很提高运算速度,特别是第2次调用的运算速度,我曾经做过测试,
差别还是很大的,这些都是遇到系统运行速度有问题后,进行过改进得来的经验,只是随便练习,是不能
体验到单实例在性能上的提高,但是在并发运行时,还是会造成一个瓶颈,这个要看服务器的硬件性能来
综合考量、调试优化的。06.函数的标准注释,这样别的地方调用时,很容易知道参数含义,会有智能提示。
这个的好处我就不多讲了,这个写的仔细,比写帮助文件都有用,特别是多人协作开发时,一定要注意
这些注释,特别是关键的函数,复用程度比较高的函数。
其实函数的命名,参数的命名,参数的先后顺序等上会花费很多精力,这个写过几年的英语不怎么好的
程序员会深有感触、我是电脑里装了金山词霸天天查,所以英语单词比以前多记了很多,其实我们用汉
语拼命命名吧也未必是坏事,有时候把我们搞得进退两难,中不中洋不洋,估计很多人会遇到这个问题。07.数据库访问工厂,按配置打开选定类别的数据库。
不可能是由于修改了数据库类型,程序一整片一整片的进行整改,或者是为了兼容多个数据库,写过多
的代码吧,这部分就是采用了设计模式中的工厂模式,使得更换数据库类型变得非常简洁方便。
不深入学习设计模式吧,还真写不出高品质的代码,说白了就是游击队与正规军的区别一样,设计模式就
是正规军,有招式、有规划的作战,搞起来很折腾,很繁琐,我们吧,自古以来吧都是逍遥派,说白了,
就是游击队作战,小仗灵活,打大战役吧还真需要正规军,没有这个还真不行,很多人都说我
不懂设计模式,看我的文章就说,看看设计模式吧,我不知道那些驳我的人自己是不是真深入以设计模式
的方式写程序的,我的系统曾经花了2个月时间进行规范化整顿,因为我觉得设计模式真的很好的,使我的
程序整体上更上了一层楼,思路更加严谨,程序更加严密。求求大家别不调查就乱发言,我也是积极好学的
人,一天一点进步,一个月一个大进步在不断发展。08.异常捕获及异常的处理机制,可不能把异常给吃掉了。
我看到很多写程序,把异常都给吃掉了,我就觉得这个人写的程序太有问题,异常怎么可以自己想怎么封装
就封装了,甚至是封装没了,不只是你自己写代码,别人也可能调用你的代码,那别人理解你的代码会变得
很复杂,还要研究你的思想,异常出现了,就应该该抛出的抛出,让别人也得到哪个异常,一般性的代码,
事务处理与异常都是成对易做图起来的,这样的代码别人阅读起来也很方便,不要搞个不伦不类的特殊处理方
式出来,这是我对那些把异常吃掉的处理方式的友善建议,不要乱处理系统的异常,请保持原样。09.数据库事务处理部分,数据库事务是需要在同一个连接里实现的。
从我自己对数据库了解的肤浅知识的程度来看,数据库的事务都是需要在同一个open与close之间才可以,
不太可能是贯穿在多个open与close之间,很多人都仿造Discuz!NT 的方式处理数据库访问,最新版本的
我没研究过,早期几个版本的dnt,我想都是针对web简单业务的,并不适合处理数据库事务方面的控制,
这方面可能定位就不一样,复杂问题想太多了,会有性能上的下降,代码的复杂度及代码量都会相应的有
所增加,有所得必有所失一样的感觉。
10.添加实体,细节请看下回分解。这里是以面向对象的思想,强类型组织编码、到底传输几个参数,对一个实体来讲,是会经常有变化,你
说是3个参数吧,有可能有时候改来改去会变成4个参数,那我们干脆就把一个实体类传输过去,那不管是
几个参数,程序就很稳定,不用经常修改了,有些说,干脆hashtable吧,哇靠,那还不如直接用“a,b”
这样用“,”符号隔开传过去算了,搞那么复杂干啥,不是不能解决问题,是要解决得有水平对吧,
hashtable里到底需要放啥?鬼才知道啊,特别是陌
补充:Web开发 , ASP.Net ,