大恶人吉日嘎拉之走火入魔闭门造车之.NET疯狂架构经验分享系列之（一）后台控制逻辑代码部分(转)

我也是本着善意把自己的代码结构分享给大家，欢迎大家用批评指点。首先我为什么把这个标题写为恶人，
因为我很喜欢招惹别人，因为喜欢跟别人交流，喜欢指出别人的缺点，偷偷学习别人的优点，所以大家都
会反感我，因为我往往是在说别人的缺点，没说说人家的优点。工作上，我也喜欢较真，追求完美，正是
这个执着的思想，使我一直没有放弃对软件的痴迷。

为什么我说自己是“闭门造车”，因为你往往深入研究了自己的东西，就很容易跟不上时代的潮流，来不
及学习新技术，因为你有个沉重的包袱需要完善维护，天天精心维护，否则会漏洞百出，往往这个原因导
致自己很容易变成井底之蛙，用一句贬义词形容就是“闭门造车”了。

大部分梦想有一个完美系统架构，我只是努力了7-8年，把完美架构架设好了，现在是想把这么自己心目
中的完美架构变成RMB，在寻觅如何才能变成RMB的过程中，完美架构不是一个人干的事情，那需要让
你每年死几次，死好几年才会提炼出来，而且超级磨练你的意志力，你会产生放弃至少3-4次的念头，会
得到很多人排斥，还要进过很多项目的实际考验才会产生出来，好东西多的是，但是没人给你讲解，不认
真去学习，就像我下载的1G的C#文档资料一样，电子垃圾一大堆，天天跟这新技术屁股后面，也难提炼
出个啥来，因为你永远跟不上时代的进步，你的积累也会变成你的包袱，除非你有惊人的毅力，不断完善
你的积累，那最起码你要连续几年不打游戏节省时间才能提炼出来，或者公司出钱给你烧，能烧出来的。

不是新技术出来了，你以前的积累就都推倒了，除非你以前的积累是经不起考验，否则是不会被推倒的，
新技术只是锦上添花而已，管理软件整体的开发思想不会轻易的发生天大的变化的，需要你不断吸收新
技术，了解新技术的长处及定位，然后再把新技术消化好，用到自己的整体架构里。
我的整体思想，见图如下 

【图01】
 

我不是你让我做啥，我能做出来啥，而是我已经做出来了，你尽管提需求，我这里都有成熟的
解决方法及思路，我这个马上可以大批量生产，你要什么管理系统？你想开发什么系统？别人
要开发6个月，那我3个月有可能开发好了，别人需要10个人开发，我需要5个就可以了，
别人说需要5个成熟的开发人员，我说5个实习生也够了，这就是我的优点，我不需公司给我烧钱
研发个什么平台出来，我现在就有，马上就见效，我为什么要求高薪？因为我没风险，我已经为此
投资了很多精力，我一直没放弃我的积累，一直没放弃完善，普通程序员心中的梦想，我已经实现了，我现在只需要等机会、寻觅机会。 

架构此系统的核心出发点：
01. 同一个代码能支持多种数据库，改数据库不改代码。
02. 有足够的扩展性，能兼容未来新技术的发展。
03. 把自己的项目经验有效积累。
04. 神速搞定大项目，视开发管理类软件为娱乐消遣，一辈子碰上几次机会，咸鱼大翻身（几十万，几百万的软件项目）。
05. 不断用新技术改进架构。
06. 精力旺盛闲着没事干，也没其他兴趣爱好，不喜欢足球，不打游戏。
07. 软件这东西干好了，来钱的确快，而且可以空手套白狼，不需要多少资本。
08. 写一个程序可能是C\S的也可能是B\S的，同样的代码可以任选用Service、WCF、Remoting、WebService 中的任何一种运行模式。
09. 建立通用的可扩展的权限模型，做一个权限搞定全部商业软件的权限，一次性突破个彻底。
10. 支持分层部署在不同的服务器上，例如Oralce数据库服务器、商业逻辑服务器与Web服务器（不装任何Oracle组件）彻底干净的分开。
11. 采用新技术后，不会彻底被打翻推倒，局部的改进不影响整体的架构及已有的积累。
12. 一切以服务存在，面向对象强类型编程。
13. 要经得起折腾，你想怎么折腾，我陪你怎么玩，快速满足你的苛刻要求，可以很快吸纳好建议。
14. 代码通俗易懂，可以大批量模仿生产，我们不是玩技术的，我们是做项目赚钱的，客户是不管你玩了什么技术，客户只看效果。
15. 客户不要过程只要结果，我们平时积累好做好准备，只要接到单子最快的速度搞定，客户其实没空跟我们折腾也没那个义务。

废话少说，看图。

【图02】
上图，主要是后台代码部分，后代代码部分的架构，按逻辑先后顺序讲解一下
01. DotNet.Common.Utilities：我的通用类库部分，经常用的类都封装在这里，不断完善，不断积累，非常好用。
02. DotNet.Common.DbUtilities：数据库访问部分，这里能实现多种数据库的访问，而且实现了换数据库彻底不改代码的能力。
03. DotNet.Common.Model：模型定义部分，主要是我系统都处理那些模型，说俗点儿就是哪些类。
04. DotNet.Common.Business：商业逻辑部分，这里主要是编写核心的商业逻辑，玩法，这个积累是很重要的。
05. DotNet.Common.IService：服务接口定义部分，这里主要声明，我有那些服务方法，都提供什么接口。
06. DotNet.Common.Service：服务实现部分：这里就是SOA体系的服务程序部分，对外提供的服务，都通过调用这里实现。
07. DotNet.Common.RemotingServer：远程服务部分：主要是实现了Remoting的服务器端部分。
08. DotNet.Common.WindowsService：Windows服务部分：主要是以Windows的服务的方式实现具体服务。
09. DotNet.Common.WebService：Web服务部分：主要是以Web服务的形式，把自己的服务进行实现。
10. DotNet.Common.WebService.Client: Web服务的客户端调用部分：主要是实现WebService的调用实现部分。
11. DotNet.Common.UILayer.Utilities：传统的C\S项目部分，通用组件，采用这些组件快速提高开发效率。
12. DotNet.Common.UILayer.WinForms：传统的C\S项目部分，每个子程序可以单独运行，也可以变成母程序的模块。
13. DotNet.Common.UILayer.WinForm：传统的C\S项目部分的主程序部分。
14. DotNet.Common.Web：传统的B\S项目部分。
15. DotNet.Common.Example：标准例子程序部分：方便别人学习我的系统架构，可以快速入门，有简短的样例代码。

 

【图03】

 主要是后台模型定义的结构图，这里几乎没有商业逻辑代码，纯粹是模型的定义部分。
什么是钱？模型就是钱，例如让你做个简单工作流，你都搞不明白建立几个表，都需要那些字段，
这些你都有积累，表结构都在手，那不管是用Java,PHP,C++你都可以快速进入状态了，
其实我们开发管理系统时，到底建立什么表，都应该需要有那些字段等，换句话，在建立领域模型
上消耗的时间是很长很长的，我们经常在折腾来折腾去，搞来搞去，花了很多很多时间。
话说大了，什么叫某领域专家？模型Code对应的就是就是领域专家，这些你积累多了，日后不管
用什么技术开发，都会快速提高开发速度，大家很容易忽视珍惜自己的模型，做一个丢一个，等
做了N年后，才会发现模型的积累是比写程序还更重要的。

 

【图04】

 上面的【图04】的功能，主要是一个 数据表及数据库字段的定义 功能，主要是为考虑了以下几点
1：由于我们的英文水平不好，又不喜欢用中文拼命命名更不喜欢用中文命名字段名，所以导致经常会
有中不中洋不洋的字段名，甚至是动词名字乱来的可能性，包括我也是，所以字段名是经常变的，不能
怕变，也不能怕增加什么的，我们只能解决这个问题，我都在程序里定义好常量，然后SQL语句里用这
些静态变量来引用，这样我字段名一有变化，我程序里所有其他的地方都会报错，我就很好修改程序，
甚至是用另外命名的方法，修改一下很方便，不会出现运行时才会发现错误的情况。
2：也是为了表名、字段名在程序运行阶段可以进行设置，例如我用了你的类库，但是我的表结构跟你
不一样，我可以通过配置文件进行配置，然后程序会把这些静态变量进行赋值，这样修改一个变量，全
程序里都变了，只需要赋值一次就够了。
3：表名、字段名的注释，我是跟着程序走，我写程序时，很容易找都这个表的结构说明，不用再跑到
数据库里看，或者再打开其他设计器什么的看，这个虽然是个小小的改进，但是时间长了也不会丢失
表结构的说明，很管用，我也建议大家这么做。

经验总结：以前是手工写这些代码，工作量大，大家都排斥，后来用了代码生成器，不用自己写了，很
省事了，三下两下就可以把这些代码生成好了，但是SQL语句里完全用常量，也的确有点儿困难，但是
付出总会有回报，当你表明字段名改变了，程序也会非常稳定，甚至你都可以很放心，否则数据库表名
变化了，字段名变化了，会搞死很多人的，大家都不敢轻易改正表结构，命名知道命名错了，也不敢改。

 

【图05】

上面的【图05】的功能，主要是一个 数据库的映射 功能，主要是为了以下几个功能做了扩展余地
1：你编写的软件，可能需要跑在别人的数据库上，很可能别人的数据库表名字段名与你的不一样，
你可以做个映射，这样，你的程序就可以在别人的数据库上平滑的运行了。
2：由于我们的英语水平不好，经常会发现我的表名命名、字段名命名不规范，经常需要修改，
我们可以在程序里修改表名、字段名，但是数据库里可以不修改，还保持原有的命名，这样对
数据库的稳定很有帮助。
3：同一个公用类库在不同版本，不同的项目里，可能表名字段名会有变化，这时有个映射功能
也可能会解决这个问题。
4：很早以前我研究PHP版本的PostNuke（国外比较有名的开源）, 做过2个iBATIS的项目（美国外包），
他们都是这么做的，所以给我的印象也比较深刻一些。

经验总结： 这个是个鸡肋、属于过度设计，研究这些浪费了我几个月的时间，只是玩技术而已
实际项目中，客户根本不在乎这些，也没遇到过需求这么复杂的项目，纯粹是玩技术而已。 

 

【图06】
上面的【图06】的功能，如下
1：实体类的定义，告诉我实体到底有那些属性。
2：这个实体是可以远程传递的[Serializable]的。
3：这个类的代码就是表明这个类有啥属性，Domain 域的定义功能，只有少数几个方法。
经验总结： 向对象这么多年了总要靠近面向对象吧，要强类型吧，写程序天经地义应该这
么写，只有们外汉不这么写，这个以前也人工写，大家也排斥，现在用代码生成器了，不
用人工写了，只要设计好就可以了，用起来很方便。 

【图07】
主要是 表结构的定义的实体对象及，实体类的实体对象方式显示，表明一下我命名的严谨，
由于我上大学才学英语，本人的英语水平很差，但是天天努力一点点，比人指出错误，我也虚心学习的。

 

 
【图08】

 上图主要是我的接口功能定义部分，这部分的主要功能如下
1：我的系统到底有那些服务接口提供了？
2：每个服务里到底有那些方法？
3：每个方法到底有哪些参数？
4：不管是WCF,Remoting,都是需要定义接口的，我这个以后与新技术的扩展是不冲突的。
假若你写的程序还没有接口，那是需要注意了，接口到底有什么作用，需要彻底理解的。

【图09】

服务程序部分，主要实现了具体的服务控制代码部分，事务控制，并发控制，日志记录，权限控制、程序运行性能测试等等功能，
服务程序部分也完全按设计模式的知道理论使用了工厂模式，开闭原则等，相对来讲还是比较合理的。
 

错别字请帮忙支出，我都无私的把自己的积累经验总结写出来了，大家也无私的把我语句不畅通，
错别字，标点符号错的，都帮我支正一下，我尽快修正。

 
上班一天糊弄8个小时，还可以发几百个大洋，写这文章苦干几个小时，能得到大家的吆喝就很好了，大家多鼓励一下。
有时候自己的东西不是不敢写，写文章也是需要花成本的，也是需要代价的，一些写到深夜了，继续战斗一下，分享经验吧。
也不能光吹牛吧，大家还是看不出来实质性的东西，我也没办法了，接着只能贴代码了，这样应该会满意了。

 

 

导读：

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

转：http://www.cnblogs.com/jirigala/archive/2009/06/16/1503913.html