我的powerbuilder框架,经过三套软件的开发逐渐形成并得到完善

QQ群请加: 6539042(powerbuilder11&SQL)  

我的框架是这样的。(C/S数据库直连)

1. 窗口框架MDI+sheet，w_main为主窗口,w_child为程序第一个子窗口，并不能被关闭，m_child从m_main继承来，和m_main一模一样。w_child窗口可以放流程导航图，或者及时消息提示，或者图标按钮等。子窗口打开后显示在w_child的window菜单里。

2. 用户信息，需要全程使用，为满足封装要求，设置一个global_var对象，将全局函数和变量封装在里面。

MIS系统中随时会用到userid,username,部门，权限等，所以user登陆后，必须将信息一次检索到本地，你可以设计一个struct来存放。

而 global_var里的变量一般是需要先行检索到本地的FK表，一些常用的droplistdown的选项等。一些数量少而经常用到的数据必须提前检索到本地，而不需要每次都查数据库。比如用户列表，部门列表，分局列表，另外一些下拉选项用到的字典，FK表等，一般放到datastore里。

global_var的函数其实原来是全局函数，只不过就于形式而包在global_var这个对象里而已。比如dw排序，droplistdown,listbox填充，droplistdown,listbox选择项读取，字串加密解密，菜单权限设置，自定义错误消息，子窗口菜单权限设置等。都适合作在里面。

3. 权限与菜单。我设计的菜单其实只有三个：m_main,这个会根据窗口的多少而不断变化，每次变化后，m_child重新继承一次即可。另外是m_sheet用作只有detail形式的编辑窗口，功能按钮有：导出，保存，取消，插入，修改，删除，审核，排序，数据过滤，导出过滤，打印等。还有一个是m_master_detail用于有master和detail部分的编辑，如采购单，有表头信息和表身信息，m_master_detail只不过将表头和表身的编辑功能分开操作，稍微复杂一些。

另外建立一个t_menu_list和t_menu_authorization，分别可以添加菜单，后者管理用户权限。后者是前者和用户表的迭乘。

用户登陆时，将其主窗口和子窗口的权限检索到本地datastore里，然后界面未开启前，用一个全局函数来设置m_main菜单权限。就达到了权限设置，而用户打开某个子窗口后，再对子窗口的菜单设置编辑权限。比如可insert,但不能delete等。MIS和ERP系统中,因为系统是公用的，编辑界面往往也是单据察看的界面，如果不设置详细的权限控制，系统是无法满足客户需求的。一些简易系统只控制到主菜单里是否给user开启某个窗口，这样是不行的，因为还有其他人要使用改界面来查询或者打印，导出等。

4. 表的命名。遵循system_menu,system_menu_authorization,system_user,system_user_userclass,inv_100001,inv101001这样的分模块分阶方式。

5. pbl的划分。在主pbl里放尽量少的东西，各pbl按功能划分，利于后期维护，比如system1.pbl,menu1.pbl,winv1.pbl,dinv1.pbl,sstruct1.pbl按业务逻辑划分后面好找相应的对象。

6. 窗口的事件尽量全部用自定义事件。比如ue_isnerrow(),ue_modify,ue_print()这样不管你是喜欢用菜单还是用按钮触发，通通postevent("ue_isnerrow")这样就可以了，而且察看比较集中，更重要的是，当你删除一个按钮时，不会伤到代码部分。当然。如果你在窗口上放了一个按钮叫"insert"的话，仍然需要用用户权限来设置它的enabled,一般情况下，我作的界面上都没有按钮，都通过菜单的toolbar操作。操作习惯比较统一。

7. 对控件的扩展。如果一些功能用的多，考虑封装成自定义对象(user object)或者可视对象。把一些重复利用的代码封装起来。减少重复编码。

8. 对datawindow的protect属性的开启，不要硬写代码。我的做法是写一个全局函数，传入datawindow和一个控制字符串，如：gf_dw_protect(dwx,change_type,control_str)，如gf_dw_protect(dw_1,10,"-1-2-3-4-5-8-10-")，这样来改变，每次修改时，只需要确认栏位的编号即可。而不用dw_1.object.col_name.protect = true 来写。这个函数也可以扩展实现背景色的改变，从而使用用户操作更直观。

9. 自定义报表，其实对用户层面来将，无所谓自定义，因为用户不专业，即使提供再好的工具，用户没有对数据结构和sql知识的了解。靠用户定义报表是可笑的。我的做法是设计了三个界面:1.报表挂接与授权，2.datawindow源代码插入。3.报表显示。

其实虽然是有这三个界面，用户能完成一半的简单的如扩展栏位，修改显示字段，少量修改条件等。真正复杂或者新创建报表还是需要自己来弄，不过对于多变的，或者临时的，至少我这三个窗口提供了一种不需要修改程序就可以让客户用报表的便捷途径。这样不影响到客户程序的变更和更新问题。datawindow在pb或者infomaker里创建，然后将source code粘贴过来保存在我的数据库里就可以了。每次用户查询报表，动态生成报表。

最近到客户那里，看到客户居然挂了上百支不同的报表，而且各分公司的报表还不一致，我突然感到，如果没有这三个界面。估计我早被烦透了。因为我可以给一些datawindow的代码给客户让客户去修改使用，满足一些差异化需求，而不需要修改程序代码。而且对于多变的报表，自己作也不划算。没什么钱赚。

10.写任何代码时都考虑重用，将特殊代码单据写到一块，将通用部分写到一块，这样移植时修改最小。而且成本效率很好。

11. 对于复杂的企业运用来说，纯web是不适用的。通过c/s直连能解决一些小MIS问题。但对大型运用，还是需要三层结构。不过问题的平衡也就在此，小软件项目不能承担大的成本和开发费用，三层结构开发更烦琐一些，调试都比较麻烦，但更适合大项目。当然也有用远程终端服务和思杰（Citrix）来解决互联网运用问题。当然电讯项目运用TUXDE的也很普遍。现在pb11出来，用webservice调用也是可以有一些方案的。

12. pb的datawindow的灵活使用就可以构建任何复杂和简单的报表，不需要借助其它报表工具，所以没必要为pb设计报表工具。

13.pb让你更关注一些业务逻辑的运用，而不太受到技术进步和淘汰的影响。因为数据库和信息管理始终都是存在的。