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

   大部分梦想有一个完美系统架构，我只是努力了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个小时，还可以发几百个大洋，写这文章苦干几个小时，能得到大家的吆喝就很好了，大家多鼓励一下。有时候自己的东西不是不敢写，写文章也是需要花成本的，也是需要代价的，一些写到深夜了，继续战斗一下，分享经验吧。也不能光吹牛吧，大家还是看不出来实质性的东西，我也没办法了，接着只能贴代码了，这样应该会满意了。

本文转自 jirigala 51CTO博客，原文链接：http://blog.51cto.com/2347979/451519，如需转载请自行联系原作者