Voucher的设计 2006年4月

凭证是典型的(参考：http://www.gpskld.com)H-D-D结构(Head-Detail-Detail)

凭证头---------凭证体------------------------辅助账------------------------核算项目组合

|-------凭证体 |------辅助账------------------------核算项目组合 |------辅助账------------------------核算项目组合 对于1--*的关系，一般外键都是在*的实体里 VoucherEntry的FBillID指向Voucher

VoucherAssistRecord（辅助账）的FEntryID指向VoucherEntry

辅助账（VoucherAssistRecord）-----辅助账横表（AssistantHG）是1-1关系

客户端和服务端登陆EAS的部分代码 2006年4月

Context userCtx;

String url = "tcp://localhost:11034"; ORMRPCServiceLocator.setCurrentServiceURL(url); BOSObjectFactory.clearSession (url);

ILoginModule login = LoginModuleFactory.getRemoteInstance(); Locale l2 = new Locale("L2");

LoginContext loginContext = new LoginContext("user", "", "eas", "EASDEMO",l2, "192.168.0.153

", "lizhuang");

loginContext.put("dbType", new Integer(0)); loginContext.put("dbTypeCode", new Integer(0));

System.out.println (" before Login in ok "); userCtx = login.fullLogin(loginContext);

System.out.println(" after Login in ok ");

下边这个服务端登陆是错误的

Context userCtx;

ILoginModule login = LoginModuleFactory.getLocalInstance ; Locale l2 = new Locale("L2");

LoginContext loginContext = new LoginContext("user", "", "eas", "EASDEMO",l2, "192.168.0.153

", "lizhuang");

userCtx = login.fullLogin(loginContext); 补充这是服务端的一个登陆代码

Locale CHINESE = new Locale("L2");

MetaDataLoaderFactory.setClientMetaDataPath(UIConfig.getMetaDataDir()); LoginHelper.login("yaya", "", "eas", "wens1018", CHINESE); 步骤：1.设置元数据路径 2.调用登陆接口

性能测试脚本也是在此基础上写业务测试脚本的

读"模式系列谈之Facade模式"随笔 2007年1月

看到"门面"这个词，大家一定都觉得很熟悉。不错，这个词正是借用了我们日常生活中的"门面"的概念。日常生活中的"门面"，正是我们买东西的地方。因此可以这么说，"门面"就是这么一个地方，它们跟各种商品的生产商打交道，收集商品后，再卖给我们。换句话说，如果没有"门面"，我们将不得不直接跟各种各样的生产商买商品；而有了"门面"，我们要买东西，直接跟"门面"打交道就可以了。

--理解为商店的门面，翻译的太牵强，不如想象为医院的前台，有看到过一个更有好玩的比喻：

FACADE—我有一个专业的Nikon相机，我就喜欢自己手动调光圈、快门，这样照出来的照片才专业，但MM可不懂这些，教了半天也不会。幸好相机有Facade设计模式，把相机调整到自动档，只要对准目标按快门就行了，一切由相机自动调整，这样 MM也可以用这个相机给我拍张照片了。

Facade模式正是这样一个"门面"：我们本来需要与后台的多个类或者接口打交道，而Facade模式是客户端和后台之间插入一个中间层——门面，这个门面跟后台的多个类或接口打交道，而客户端只需要跟门面打交道即可。

--这个解释的很好，Facade模式是client与server交互过程的一个优化，是简化"客户"与"服务"交互的一种手段，注意这是一个交互优化。 使用Facade模式可以说是后台设计和编码人员的一个必备素质。我不止碰到过一个这样的后台开发人员，他们认为只要把后台功能完成了就万事大吉，而没有站在后台使用者的角度来看一看自己写出来的代码。其实，我们写出来的后台代码是要给别人使用的，所以我们提供给使用者的接口要越简单越好，这不单是对使用者好，同时对开发者也是好处多多的，至少你的接口简单了，你和使用者的交流就容易了。

而Facade模式中的Facade类正是这样一个用户接口，它和后台中的多个类产生依赖关系，而后台的客户类则只跟Facade类产生依赖关系。为什么要这么做？其中的原因十分简单：后台的开发者熟悉他自己开发的各个类，也就容易解决和多个类的依赖关系，而后台的使用者则不太熟悉后台的各个类，不容易处理和它们之间的依赖；因此，后台的开发者自己在Facade类中解决了与后台多个类之间的依赖，后台的使用者只需要处理和Facade类的依赖即可。 --使用Facade模式更多的是为了第三方调用起来简单快速，把复杂的事务逻辑封装起来 好了，闲话少说。我们下面就以几个具体的例子来看一看Facade模式是怎么使用的。实际编程中，能使用到Facade模式的情况有很多，以下就分两种情况来具体说一说Facade模式的使用。可能还会有其他的情况，大家在实践中也可以加以补充。

第一种情况，客户类要使用的功能分布在多个类中，这些类可能相互之间没有什么关系；客户在使用后台的时候，必须先初始化要使用到的功能所在的类，然后才能使用。这时候，适合将这些功能集中在一个Facade类里，还可以替用户做一些初始化的工作，以减轻用户的负担。

例如，以商店为例。假如商店里出售三种商品：衣服、电脑和手机。这三种商品都是由各自的生产厂商卖出的，如下： public class CoatFactory {

public Coat saleCoat() { ……

return coat; } …… }

然后是电脑的厂家类：

public class ComputerFactory {

public Computer saleComputer() { ……

return computer; } …… }

最后是手机商类：

public class MobileFactory {

public Mobile saleMobile() { ……

return mobile; } …… }

如果没有商店，我们就不得不分别跟各自的生产商打交道，如下：

//买衣服

CoatFactory coatFactory = new CoatFactory(); coatFactory.saleCoat(); //买电脑

ComputerFactory computerFactory = new ComputerFactory(); computerFactory.saleComputer (); //买手机

MobileFactory mobileFactory = new MobileFactory(); mobileFactory.saleMobile();

对我们顾客来说，和这么多的厂家类打交道，这显然是够麻烦的。

这样，我们就需要创建一个商店类了，让商店类和这些厂家打交道，我们只和商店类打交道即可，如下：

public class Store {

public Coat saleCoat() {

CoatFactory coatFactory = new CoatFactory(); return coatFactory.saleCoat(); }

public Computer saleComputer() {

ComputerFactory computerFactory = new ComputerFactory(); return computerFactory.saleComputer(); }

public Mobile saleMobile() {

MobileFactory mobileFactory = new MobileFactory(); return mobileFactory.saleMobile ();