大恶人吉日嘎拉之走火入魔闭门造车之.NET疯狂架构经验分享系列之(一)后台控制逻辑代码部分
2009-06-16 00:05 通用C#系统架构 阅读(11781) 评论(164) 编辑 收藏 举报我也是本着善意把自己的代码结构分享给大家,欢迎大家用批评指点。首先我为什么把这个标题写为恶人,因为我很喜欢招惹别人,因为喜欢跟别人交流,喜欢指出别人的缺点,偷偷学习别人的优点,所以大家都会反感我,因为我往往是在说别人的缺点,没说说人家的优点。工作上,我也喜欢较真,追求完美,正是这个执着的思想,使我一直没有放弃对软件的痴迷。
为什么我说自己是“闭门造车”,因为你往往深入研究了自己的东西,就很容易跟不上时代的潮流,来不及学习新技术,因为你有个沉重的包袱需要完善维护,天天精心维护,否则会漏洞百出,往往这个原因导致自己很容易变成井底之蛙,用一句贬义词形容就是“闭门造车”了。
大部分梦想有一个完美系统架构,我只是努力了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