当前位置:编程学习 > asp >>

大恶人吉日嘎拉之走火入魔闭门造车之.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 ,
CopyRight © 2022 站长资源库 编程知识问答 zzzyk.com All Rights Reserved
部分文章来自网络,