我所在是一家跨国家直销公司，在亚太某国家电子商务项目中，2011年底系统全面应用了通用权限数据访问层类库及工具类库，支持了每月万级会员加入、千万级订单；同时，在我们的项目开发过程中，完全由外包工程师来完成编码工作，应用通用权限系统框架规范了工程师的编码的风格统一、提升了开发效率。

　　此项目算是老项目，09年集中公司所有技术骨干，项目开发部总监亲自担任项目经理，整个项目封闭开发近三个月时间，交付了离线业务系统、核心业务系统、电子商务系统（当时仅完成了支持CMS、经销商信息查询等功能）。受市场拓展影响，当时仅在非洲某国家上线了离线业务系统，核心业务系统也只是使用了部分功能。由于当时工期紧张，对技术人员所使用的技术方案也未做过多强制性要求，仅以实现功能为主；因此对于后期增加功能遗留了技术隐患。

　　2011年初，公司对新业态重新进行整合，因此原来项目又被重新立项。此时原来开发人员有参与其它项目，也有人离职。最后确认由我来带领外包工程师来继续完成支持新业态的系统开发工作。在这一年中，项目内外遇到前所未有的挑战，从外部来讲，新公司开业是需业绩支撑的，因此，开业的时间、运营政策都要根据市场情况随时做调整；对应到系统上，系统的需要完成需求和实现的功能随时都可能发生变化；从内部来讲，我们的开发团队都是由合作公司派遣来工程师，大家根本就没有时间磨合，就要开始开发随时可能发生变化的系统。但系统永远要为业务服务，开发人员也要向原来的系统架构妥协。这样在2011年第三个季度我们完成了原离线业务系统改版，在亚太某国家交付一个支持会员批量加入、批量录订单的电子商务系统。

　　随着系统的上线，项目组遇到问题也就接踵而来，原系统架构更多面向于CMS内容管理平台，因此应用更多面向于网站等应用技术方案，再加外包工程师对系统框架并未完全吃透，交付代码只能说是就功能完成功能、有些地方根本没有加try、Catch; 问题最多时候，系统有将近400多个Bug, 如此一来，业务方报怨开发组、开发组也抱怨业务方需求不明确、抱怨系统框架不稳定；抱怨归抱怨，问题终要寻求解决办法，作为项目负责人，我当即想到通用权限的框架，但我也犹豫这是否是使项目发生转机的一次时机。因为我已经学习通用权限近两年时间，之前也应用它写过一些小程序。当时，新分公司业务有近一个月调整期，系统仅提供查询等基本功能，我随即按排工程师对电子商务系统数据访问层进行切换，因为我们是Oracle数据库，目前吉日嘎拉通用权限管理系统组件以Sql Server应用为主，我们将Oracle类库包括中数据访问项目中，由于前期的项目业务逻辑都写的包函数，因此我们cs代码并没有逻辑层，但我也要求工程师按照严格通用权限中的示例代码来写，同时我也明确指出，在电子商务系统应用成功，我们将在核心业务系统和离线业务系统进行全面应用。此次替换涉及近20个aspx页面，工程师从开始学习上手到完成，仅用一周的时间就搞定了。后来我又亲自在整理分页处理函数，现在我们暂时放在BasePage页里，又花一周时间对原分页函数进行了替换。经过这一番折腾，我们的系统底层一下从来的基于Framework 2.0 直接切换到Framewor 4.0;同时，在上月初，分公司重新营业，我们将替换后的系统在生产环境进行配置，到目前为止，系统运营正常。

图1（电子商务系统)

　　经过这次升级调整，电子商务系统数据访问性能明显提升。工程师手头代码也有统一的规范标准，开发效率和质量都有很大提高。

图2（核心业务系统）

　　在接下来开发中，我们计划应用通用权限管理系统组件框架做如下开发：

　　在此项目中，我们的电子商务系统与核心业务系统是用户（Oracle中)分离的，之前的解决方案是通过同义词，将数据访问打通，通过应用通用权限框架，我们将系统在业务层实现分离，即基础信息从电子商务系统数据用户来取，生成业务数据（会员、订单等）提交核心业务系统中。

　　离线业务系统整合

　　离线业务系统在其销售业务期结束后，数据将上传至核心业务系统；因为离线业务系统是基于Sql Server数据库；核心业务系统是基于Oracle数据库，前期也是由两组人员在开发，因此在编码规则上差异很大，我们计划应用通用权限管理系统组件框架对离线系统做进行统一整合。