大恶人吉日嘎拉之走火入魔闭门造车之.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里到底需要放啥?鬼才知道啊，特别是陌生人调用你的程序，那都需要神仙才能知道你当时都想啥了。
本人平生最讨厌hashtable作为参数的真想给一巴掌，除非是非用不可了，用实体类传输的好处就是，增加
了某个属性或者删除了某个属性，系统不会大面积崩溃，可以在编译阶段发现问题，而不是运行阶段，那时
候已经来不及了。

11.状态消息，细节请看下回分解。
返回状态消息里有状态码及状态信息，页面上可以根据这个来判断程序运行状态及返回的状态信息，
这个状态信息可能是多语言的，例如部分用户是在日本的，部分用户是在美国的，那就可以支持多
种语言的返回可能性。
另外一方面，我是考虑了，尽量少与服务器进行来回往来，尽量在一个往返里把想办的事情搞定，
例如我们以添加一条记录来打个比方，这个问题可能复杂了一些，我画个图来解释一下，我的基本
出发点。我系统的基本架构思想是可以按下图可以理解

客户端 - 服务程序 - 商业逻辑 - 物理数据库
例如我客户端 添加一笔数据，我首先是会如下处理步骤
A:在客户端检查输入数据的有效性。
--->
B:将页面数据转换成类，传输到服务器端。
--->
C:在服务器端进行数据验证及权限验证等(若有必要)。
--->
D:在服务器端调用相应的商业逻辑类。
--->
E:判断数据是否重复？若重复了返回相应的状态。
--->
F:数据没有重复，进行商业逻辑运算，形成SQL语句，把实体加入到表中。
--->
G:若没发生异常什么的，放回当前插入技术的主键ID，并方位成功标志信息及相关提示信息。

小节：
不可能在一个添加的页面操作里，先调用检查数据是否重复，若没重复，再调用数据插入操作，
说不定你正在加的时候，别人也在加，你刚判断数据不重复，还没来得及调用第2个服务方法，
别人正好这时候插入数据了，所以这个动作就像是数据库事务一样，需要一个动作里完成一些
列操作才可以保证系统的健壮性。
所以一个添加造作，不仅仅是返回一个主键ID，还要返回是否成功？若不成功是为啥不成功？
并放回友善的提示信息。 不知道有几个人做项目考虑得这么细致，我不信人人都这么想了。

12.记录日志功能，细节请看下回分解。
日志可能是记录在数据库里，也可能是记录在文本文件里，也可能是记录在windows日志里，这里也用了
设计模式，虽然无法跟专业的比，但是这个想怎么修改就怎么修改，也很轻量级方便维护完善，学习成本
也很低，好东西也是需要有个学习了解的过程，这个成本也是需要计算的，在公司里研究一天这个，老板
也是需要发一天工资的，系统要是没有日志功能是很恐怖的，虽然这个功能平时不怎么需要，但是系统出
了严重的问题，或者系统经常崩溃，查看运行日志，也是解决问题的一个依据一个入口，谁在系统里干了
个坏事，最起码也有希望能查出来吧？因为客户觉得你是神仙，你是无所不能的，不能让客户失望啊，甚
至客户以为你比电影上的黑客还神奇呢。
为了改进当前是谁在调用那个服务的什么方法上，也是花了点儿心思的，以前是用应编码，后来是用了反射，
不用每个方法都写函数名，方法名了，可以通过反射直接获得当前函数名，方法名了，也是提高了不少。
本系统的核心思想是面向服务编程，所以没怎么重视到底访问了哪些页面，是更重视到底访问了哪些服务。

13.异常记录、异常抛出，细节请看下回分解。
异常处理跟日志处理类似，只是需要更多的注意，我设计系统的思想是不会轻易出现异常的，因为异常会
消耗很多资源，我的系统里发生了异常，那一定是很严重的事故了，默认情况下是希望把异常发送给项目
负责员，公司的邮件列表里等，及时响应客户的异常出现情况。若异常是发生在服务器端，会把异常都进
行妥善的保存，当对系统进行维护时，对异常进行深入分析，理想状态下很生成异常报表等，我的期望是
这样的，但是我现在还没精力做这么细腻，想想都容易，做起来都需要投入不少精力的，完美无止境，光
研究技术，光想来想去是生活在空想里，先把实际项目做好，把钱赚来再解决其他次要的都来得及吧。

14.输出调试信息，细节请看下回分解。

我们很可能需要一个性能分析报告，例如每个服务运行花费了多长时间？
很可能还需要测试页面，页面上的某个事件不小心重复调用了服务方法多次，影响了性能？
很可能还需要页面的服务调用情况，是否有些服务被调用错了，都单点调试吧，也很累，
把运行结果输出在调试窗口里，也很便捷，很方便查看运行情况，也容易形成测试文档，
我做日本外包时曾经有这样的需求，说实话这个需求还是蛮高的，但是软件的质量的确
得到了保障。

15.习惯了时刻看自己的代码有几行，写了多少，总共都少行。

我比较喜欢看自己的代码总共写了几行，我觉得我写的一行代码至少有10元的成本，
所以我不会轻易少写一样代码，也不会轻易多写一行代码，每行代码都脑子里想过几
篇后写上来，当然我脑子转得也很快，几乎不需要等待时间，排版也会相当仔细，一般也
不会写过长的函数，因为那很可能是思路有问题，或者不严谨，也不会写过短的函数，很可
能没必要存在这个函数的意义，函数太长也是不好，太短了到处是函数，也闹心，有些老外
的程序，也是很变态，几乎都是非常短的函数，看也看不明白，可能是写太深奥了，我水平
还达不到理解高手写的代码，但是总是觉得，那么写程序，太琐碎了，曾经有个高手同事，
函数都是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