大恶人吉日嘎拉之走火入魔闭门造车之.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 ,
