摘要： 最近在整一个老系统，业务逻辑都是用存储过程和表关系堆砌而成，也就是说逻辑分散到系统各个地方，很难在头脑中复原完整的业务逻辑关系图。 如果当初有很好的建模设计，我们这些后来者维护、扩展都会很方便。 所以程序员，开发的时候多为你以后的伙伴考虑一下，设计不只是架构师和设计师的事。 开发即设计 阅读全文

摘要： 这段时间扩展一个老系统，面条式代码给我搞伤了。无文档，无单元测试，无讲解，只有面条…… 阅读全文

摘要： 如果您觉得 “单元测试”、“重构”、“面向接口的设计” 等等实践没有用或者没有感受到它们益处的话。 您可以尝试【重复发明轮子】，比如做一个IOC容器 或者 事务管理器，等等随便你感兴趣的领域。 当您开发出第一个版本，然后想升级优化这个项目，在继续加入一些自己的设计创意时，你会发现那个绿色的杠杠是多么的好。接口对于扩展是多么的有用~ :) PS: Banq讲他开发JdonFramework把S... 阅读全文

摘要： 在上文中我使用协议表进行协议和协议处理函数的统一注册及管理，在开发原型的过程中发现一个问题： 呵呵，不好意思，这是我开发设计时的思考速记。发上来这个图也算是把自己的实践思考过程展示出来，让大家指点。 所以就像图上写的，二次开发协议的程序员将会定义很多函数名不同，但参数和返回值相同的函数。这不是很好~~ 因此我将设计改为下面这种形式，我直接发代码了，绿色背景色标注的代码为新改进的。 using S... 阅读全文

摘要： 问题域描述:开发一个协议命令处理系统，也就是根据接收到的不同的协议命令，做不同的事。下面是协议定义的部分(总共有成百上千个协议)。第一版本的协议结构设计：如下面这张图。 这附图主要是协议结构的构造，协议处理在其他地方暂不考虑。问题就是图中画线的地方。 有很多具体协议（成百上千个）这样设计会产生很多具体协议子类。如何才能避免产生大量子类的设计呢？ 设计改进，第二版设计：图示简短描述：构造一个协议表，然后把协议和协议处理函数注册进去。 等待客户端请求命令到来，服务端查找协议表 直接取协议处理函数 进行处理。PS: 第二版设计使用了四色原型的表示，用的可能不正确。就当是给需要的朋友一些参考吧。:)在 阅读全文

摘要： 设计模式有 创建型、结构型、行为型模式。 彩色UML分为 时刻时段、角色、PPT、描述四种架构型。 (个人理解：这四种架构型是对类ERP的企业业务系统的抽象，十分完美和有用！但是有个问题对于【基础框架】的设计呢？比如Spring、JdonFramework、工作流引擎、任务管理调度执行引擎，我现在也在探索能否用彩色UML的四种架构型来进行基础框架的设计开发，所以才有了下面的遐想。另外设计模式属于更... 阅读全文

摘要： 参考这个朋友的随笔：http://www.cnblogs.com/dongzhiquan/archive/2010/07/30/1994584.html 第二段： 2.解决此问题的一个方法是：在唯一作用是帮助调试的服务应用程序中创建一个临时服务。 可以将两个服务都安装上，然后启动此“虚拟”服务加载服务进程。临时服务启动了进程后，就可以使用 Visual Studio 中的“调试”菜单来附加到服务进... 阅读全文

摘要： 一直以来我都是将自己实践过程中的小经验和在网上学习到的知识记录在个人的知识库中。 现在想慢慢都发布出来，和大家分享。由于水平有限，我只发些实践心得，希望不要误导到其他朋友。 放几个我知识库的截图： PS：个人建议大家可以整理出自己的知识库，对工作和学习都有很大的帮助~ 阅读全文