通用的N-Tier模型合理么？

        现在的通用N-Tier模型很合理了么？ N-Tier的目的是什么？不就是为了清晰么？现在的N-Tier都有很理论化的色彩，在实际的应用中，往往为了保持那点清晰性，不得不让人破口大骂。

        尤其是一个有着多个子系统的复杂系统里，如果有两个或多个子系统处理的数据之中，还有暗昧难明的关系，这个复杂度不但不会被现在的N-Tier模型所简化，相反还用了另一种复杂来替换当前的复杂，而且还是一种让人思维极度混乱的复杂。

        横着切出来，看起来似乎隔离得不错，但实际上，在UI层需要驱动某个元素时，进行反向作用时，这个就显得捉襟见肘。

        在通常的三层结构模型中，控制中心并不在UI上，而是在逻辑层上，这意味着，需要通常驱动的中心就在逻辑层上，逻辑层由于是一种类似于“后台”的模式进行运作，在对用户交互性较强的开发中，显得力不从心。

       按感觉比较舒服的方式应当是：逻辑界对UI发出指令，你给我变变，然后UI界才发生变化，对数据访问层说，我要xxxx，数据数据访问层给出数据，逻辑控制层再进行处理。如果用户发生交互，则由UI层返回处理要求，逻辑层进行处理，然后再反馈要求，此时，逻辑层再次陷入被动，实际上，这并不是一个比较漂亮的模型，不过，一般三层系统针对中小型系统及少部分偏大一些系统来说，是完全足够的，因为其中逻辑层显得模糊的部分可以忽略掉，维护起来只会增加一点点麻烦而已。

        至于更多N层结构，矛盾更明显，像微软的Duwamish所演示的架构，简直就是一发而动全身，如需要改动一个地方，马上就开始雪崩，许多层次都会被牵着走。例如，界面上加了一个需要显示的字段，呵呵，哭吧。

        分层必要吗？有必要。但分层的方式都对吗？不一定。个人认为，无论任何系统，在分层的情况下，还必须需要一个处理中心，自上而下贯穿所有的层次，这个处理中心不需要专门用于与各层进行直接打交道，了，也就是说，它是一个可以让各个层次可以自由穿梭往来的通道。它本身相当于一个外观模式，但这个外观模式与通常的设计模式又有所不同的是：它是作为一个灵魂实体实在，它需要暴露任何细节。

        初看起来，此处理中心严重违反了数据封装特性，其实不然，任何系统都需要一个相对紧密的交互核心，该核心原则只有一个：清晰。需要任何层次都可以直接通过它来进行交互，这样就可以把多层系统的开发简化，任何一层系统需要进行与其它层次打交道时，都仅仅需要考虑与一个目标进行打交道。

        这个中心需要处理成为多面体的形态，然后把各个层次进行粘贴在上面，这样的系统，就可以解决大部分问题。
       最早的三层结构，实际上就是通过逻辑层来粘合其它层次，但在N层结构中，则恰好让一切变得更加混乱了。

       系统的层次，要以多面体的观察角度去思考，而不是一个平面，例如：两层系统中，实际上就是两个面，三层系统中，实际上就是三个面，这都不是问题，但是，如果你一旦要处理成为四层或更多的层次，就不能不采用立体模型来进行考虑。

       处理中心设计的关键在于，对其它的任何层次都是再次外部包装，它本身唯一需要提供的就是层次间交互所需要的内容，也就是一个具有代理性质的中转点，该中转点不应当对于任何其它层次产生了依赖关系的类有哪怕是一点点的关系。

       对于一个有多个子系统的系统来说也是这样，它仍然需要一个中心系统，其它系统仅与中心系统打交道，并可以从中心系统获取任何所能允许的其它系统的数据或资料。

       基于立体模型的处理，可以有效地避免各个层面发生大面积相交的情况，可以把各层间的交互浓缩至最小，只要能够保证相交点稳牢性，就可以使得各个层次在维护起来各不相干，当然，这可能会更麻烦一些，但是，这可以最大限度的保证连锁效应的降低。

        另外，在开发时，应当预留一个类似于"其它"的层次用于堆放垃圾也是一个好主意，比如一些，在使用各个层次突然发生困难时，但却有直观的操作方式时，可以把该代码往垃圾层里丢。
        这层的最大意义并非是对于系统构建有什么直接的意义，它的意思关键在于：需要再次重构。
        这可以保证开发时，在充分前冲的情况下，尽量把看似还不合理的代码都放在一起，尽管会越堆越臭，但总比垃圾散布在各个层次要好得多。因为它们可以在你有空的时候进行集中处理。

         需要注意的是，重构并不万能，所以该层次不是万能的，使用这个层需要在非常不明确的概念前提下才能够往里面放代码，这个层中的代码本身也应该是杂乱的，但它却是很有用的。