企业应用架构模式（二）——数据源层架构（1）

        上一节我们讲到了，企业应用架构中的三层架构。本节先简单讨论一下三层架构中的数据源层的架构。

        《企业应用架构模式》一书，想必多数人都看过。其中对数据源层给出了很多的架构方案。但它忽略了一个问题。那就是最底层的问题。具体来说，数据库的容量是有限的。表的容量也是有限的。一旦容量超标，那么，尽管你使用了它的所有架构，那么，一切均无济于事。因为，你面对的将是：要分库，同时也要分表。这时，你猛然回头，你会发现，目前的所有PHP开发框架，均不支持你的这一行为。你不得不改底层的这些东西。这一变更，会给你的应用带来多大的修改，你甚至都不知。于是，杯具就开始了。

        所以，对于大的应用架构，特别在大型互联网应用架构，你就是在数据源层不使用中间件，那你必须为中间件留下接口。由此，我们会发现，当你要加载一个数据库链接时，你的链件条件是，库与表同时要指定。

        最常见的做法，比如，使用用户名的HASH，取结果的第一位定库，第二位定表。这样你有16个库，每个库中有16个表。这时，我们需要一个DatabaseManager的类，作为链接的前置操作。此类当然是一个抽象类。由你继承实现。以保证当前的算法符合你当前的应用的需求。因为有了多个库，因此，必须要有ConnectionManager类来管理。这样，同一请求中用到多个链接才能保证同时存在。

        可以看出，正是由这些类的存在，也就为您以后要使用中间件提供了独立的变更的类，不会影响到其它的部分。自然，如果你在这些类中，直接将常用的中间件的接口写好，则今后使用更加方便。

        数据源层，对于多种数据库的支持，现有的PHP框架中，很多都实现了。包括象玩具级别的CodeIgnaiter，它也用动态继承实现了多数据库支持。但如果你对它分析一下便知。数据库链接的部分没有独立成为一个类，使得数据库类相当复杂，不符合面向对象的单一责职的原则。这当然是对大型网站来说的。一个企业网站，超小网站，用它是足够了。但从前面我们所讲的情况来看，它是不能方便地改成大型网站架构的。

       

评论

1 楼 flashjay 2011-04-24  

期待下文...