ASP（Application Service Provider）模式应用与普通应用之间的一个重要差别是ASP系统需要管理多个客户的数据。不同客户之间的数据完全独立，没有关联。不允许一个客户查询另一个客户的数据。即使多个客户共享一个数据库，对单个客户来说，其它客户的数据可以看作是不存在的。 这里主要讨论在J2EE应用中如何解决这个问题。当然，这里讨论的方法对于其它架构的系统可能也适用。

方案1：单数据源，单套表。

所有客户的数据都存放在一个数据库的同一套表中， 在部分表中增加标示字段，表明该记录是属于哪个客户的。具体哪些表中要增加标示字段当然要看具体应用，不过我觉得可能大部分表示实体对象的表中都需要加。在很多查询条件中都需要包括这个标示字段。即使是用户自定义的查询，系统也需要在查询条件中加入该字段。

优点：数据源和数据库的管理都比较简单。数据源管理方面和普通的J2EE应用没有差别。

缺点：增加程序的复杂性。如果应用比较复杂，很多数据表都需要加入客户表示字段，很多查询都需要包括该字段，会比较麻烦。如果有遗漏，特别是查询条件中遗漏该字段，就会造成一个客户看到另一个客户的数据。另外，需要在系统的安全性方面做比较细致的设计。比如，某个功能通过在URL中包含某个实体的关键字以查询该实体的信息，或对该实体进行操作。在普通应用中后台只需要根据关键字查出该实体即可。但是在ASP应用中，就必须额外判定该实体是否属于当前登录用户，或者要在查询中条件中加入客户标示。当然如果有办法自动完成这样的检查或者自动修改发到数据库的查询条件，这个缺点就可以避免。只是我现在还没有想到这样做的好方法。

-------------------------------------

方案2：多套表，多数据源

数据库中每个客户一套表。可以是MySql, PostgresSQL, SQLServer中的不同数据库，或者Oracle中的不同schema。在应用服务器中配置不同的数据源，或者使用不同的连接池。 在访问数据库，需要得到数据库连接时，根据当前用户所属的客户选择合适的数据源或者连接池。

优点：不同客户的数据物理分离，安全性比较好。除了获取数据库连接部分的程序以外，其它程序和普通应用没有两样。不同客户的数据可以放置在不同的数据库服务器中，分担数据库服务器的负荷。

缺点：数据库连接的利用效率不高。ASP模式的主要客户是中小企业。这样带来的结果是客户数可能会很多，但是单个客户的用户数和并发登录数都不会太多。在系统这边来说，则是数据源或连接池很多，但每一个的利用效率都不高。在数据库服务器这边仍然会有很多连接，因为每个数据源或连接池都需要保持一定数量的可用连接。这样通过连接池共享数据库连接而减少总连接数的好处被大大削弱了。 另一个缺点是如果需要增加客户时，需要在应用服务器中配制新的数据源，或者修改应用自己的数据库连接池配制。某些情况下可能无法作到在应用不中断的情况下使这些配制生效。

------------------------------------

方案3：多套表，多Schema，单数据源。

这个方案基本是方案2的变种。很多数据库提供Schema，比如PostgresSQL中，同一个数据库下可以有多个Schema，Oracle中，每个用户就是一个Schema。即使用同一个用户登录数据库，只要在表名前加上schema名字，就能访问不同schema中的表。不同客户的数据就可以存放在不同的schema中。这样就能用同一个数据源或连接池，只是在所有的表名前要根据当前用户加上合适的shcema名字。如果要程序员自己这么做当然是很麻烦的。但如果用Hibernate就方便了。因为Hibernate中可以配制default schema，Hibernate在生成SQL时会自动在表名前加上schema名字。 因此如果使用Hibernate实现该方案就需要多个SessionFactory，每个客户对应一个SessionFactory。除了default schema以外，这些SessionFactory的配置完全一样。当程序需要SessionFactory的时候，需要有一个分配程序根据当前用户选择合适的SessionFactory。这些SessionFactory可以在系统启动时根据配制文件全部建立好，也可以采取lazy initialize的方法，这样也能支持动态增加客户。

优点：除了方案2的优点以外，共享数据源或连接池，效率更高。

缺点：对实现手段有一定依赖性。使用Hibernate会比较容易实现，其它方式我不清楚。每个SessionFactory都会有一定开销。多个SessionFactory会增加这部分开销，增加到多少程度，对性能有多少影响还有待测试。多个SessionFactory的情况下，二级缓存会否互相干扰，还是每个SessionFactory有各自自己的二级缓存也有待测试。

------------------------------------

所有以上方案都是所有客户共享同一个应用（WAR或EAR）。这种方式有一个缺点，不过这个缺点和数据源无关。如果用户可以以点菜式的方式选购不同功能，也就是说虽然不同客户共享一个应用，但是提供给他们的功能是不同的。这种情况下，程序中会有很多地方要判断用户是否可以使用某功能。这会带来另一种麻烦。这个和权限控制有类似，也许可以用Acegi之类的框架解决。但和权限控制又不完全一样。因为有时简单地提示用户他无权使用某功能可能不够友好，而需要以一种更优雅的方式提供用户降级过的系统功能。当然这个和具体应用有关，这里就不展开了。

------------------------------------

方案4：多套表，多应用 这个方案和以上方案不同，除了数据物理分离以外，应用也物理分离。每个客户有各自自己的WAR或EAR。如果使用方案3中的多Schema的方法，那么数据源可以共享，每个应用的SessionFactory有不同的default schema。

优点：应用简单。这样的应用和普通的J2EE应用没有任何区别。支持高度定制化的系统功能。每个应用基本相同，又可以有很大差别。比如用户没有选择的功能更本就不部署。

缺点：应用服务器中每个应用都会有一定的开销，占用一定的固定的内存。这个开销来自于应用服务器管理应用的数据结构；每个应用的class loader，和读入的类的字节码（应用服务器会判断出不同应用的同样名字的类具有同样的字节码，从而只保存一份吗？对次我表示高度怀疑）；每个应用还可能会有自己的线程，比如任务调度线程。这些开销可能会使一个应用服务器能部署的应用不会太多（和ASP模式的潜在客户数比较），从而在客户数比较大的情况下需要增加应用服务器的数目。

前面的讨论中留下了一个问题，还没有分析完。就是表示“币种”的数据类型。因此继续讨论的话就要超出了面试题目的范围，所以另开一文。

如果对币种信息的要求只是为了区别不同Money对象所代表的货币种类，以保证只有相同币种的Money对象才能进行计算，那么无论是String, int还是enum都够了。但是，在一个稍大一点的项目中，要求可能都不会仅限于此。比如需要在显示金额的时候能显示正确的货币符号，或者一些系统中还需要显示3位的币种代码，比如用USD表示美元，RMB表示人民币。在有用户输入或者和其它系统交互的情况下，还会需要判断输入的数据是否是合法的，系统支持的币种。有这些需求的情况下，自然的，我们需要一个单独的类Currency。至于在Currency内部使用具体什么类型，参见前一篇中的讨论。

因此，Money类应该是这个样子的：

public class Money {
    private Currency currency;
    private BigDecimal amount;
   
    public Money (Currency aCurrency, BigDecimal aAmount) {
        ...
    }
   
    public Money add (Money aMoney)
    throws IncompatibleCurrencyException {
        ...
    }
   
    public Money subtract (Money aMoney)
    throws IncompatibleCurrencyException {
        ...
    }
}

如果系统中需要由用户来维护系统所能支持的币种，那么一般需要在数据库中维护一张表，此时Currency就是一个可持久化类了。

关于这个设计问题，还请参看我前面翻译的那篇“Prefactoring”的2.6节。虽然那篇文章主要讨论的是分析和领域建模阶段，但是很多讨论对于设计阶段仍然是有效的。