Flash / Flex 学园

作者:Shashank Tiwari, Jack Herrington,Elad Elrom和 Joshua Mostafa
AdvancED Flex 3中文翻译　by arrowyoung
(注:请勿使用商业用途　如有任何问题请联系我:arrowyoung@126.com)

第一部分 利用强大的Flex 3

第一章

利用架构和设计模式

Adobe Flex 3,其框架、相关技术（Flash 平台）、相关工具（编译器和调试器）、IDE（Flex Builder 3）和服务器端网关(BlazeDS 和 LifeCycle Data Services) 让您可以建立复杂有效的丰富互联网应用程序（RIA），它能帮助你按时并在预算内得到具有丰富交互性应用程序。但它不是用来写你的业务逻辑和应用程序流程的，这一点要注意。

当应用程序只有有限的范围和复杂度时，我们知道业务逻辑和应用程序流程是很容易实现的,如果范围和复杂度增加时，事情会变得不好控制。当你的代码文件越来越多时，程序结构会变得不合理,业务逻辑的实现如果没有好的规划和设计，开始代码灵活，往后会越来越难于修改和增加新的功能。除此之外，应用程序流程根据要求的变化而变化会变得极其难以处理和维护。所以，当我们准备去部署这个应该程序的时候，它是不可维护的。如果你要避免这种情况，你自始至终都要使用简单干净的设计。

在整个应用程序开发周期，不断地制作可维护和灵活的应用程序，可使你有一个良好的编程习惯，长此以往，你将变成一个更好的程序员。如果你已经有了一些或所有的这些优点，你将能更好的利用它们。

在制作一个丰富、健壮的应用程序的时候，你也许希望你的朋友的一些良好的建议，以提高你的技巧、耐心和毅力。这本书就一个朋友。在这本书中能看到大量的建议和非常好的源代码，它是一直以来努力的结果。

我们现在开始吧

在这一章中，我们的重点是如何去设计和架构一个灵活、可维护和可扩展(按照用户的期望)的丰富互联网应用程序（RIA）。我们可以根据需求在理论的基础上进行讨论。有大量的图解的例子。

从结构的角度，我们把这一章分成四个部分：
■    根据实际的例子了解架构和设计原则。
■     总结这章内容的好处和挑战架构和设计原则
■     测试现有的架构框架
■     选择现有的框架并且从零开始

我认为并相信一个好理解的架构和设计模式没有一个特定的架构或微架构去参考,我们将在一个公正的基础上去比较现有的框架,一旦通过我们的基本要求,我们就能选择出比较好的框架。

在这本书中我们不会去区别架构模式和设计模式，因为我们不需要这样做。

采用架构和设计模式

本节会用一些常用的方式去解决常用的问题，一般称为设计模式或简单模式，它们有时超出架构设计范围。正式的分类喜欢去按以前的架构去分类，像架构、微架构，概念架构.在这本书中，我们仅仅是帮助你怎么应用这些模式，以使你下一个项目成功。我们要建立一个健壮的、可维护的应用程序就需要一个好的模式。

首先你可能会问，这些模式是别人写好的并且已经有很多人用，为什么我们不马上就开始写一些应用程序实例呢？为什么我们会先犯一些错误，然后回过头来再来纠正这些错误呢？像模式世界中的其它问题一样，这些问题的答案既不是统一的，也不是很好理解的。从著名的四人帮写的书（《Design Patterns: Elements of Reusable Object-Oriented Software》作者：Erich Gamma, Richard Helm, Ralph Johnson 和 John Vlissides,基于C++和Smalltalk）开始，形成了一股对重复出现的问题进行归类的潮流,导致了模式数量的增长，从23种模式增长到了数百种，它也导致了分类模式成为一种具体的技术，举个例子来说：J2EE的设计模式相关与具体应用案例，就有AJAX模式。丰富的模式会使许多开发者在有简单的解决方案的时候还要去过度的设计和架构。它误导我们花过多的精力在这上面，导致我们的应用程序不好理解并有很多问题。然而这并不意味着它们是无用的或没有价值的。我们需要有效地利用模式的做法和经验，并不仅仅是知道理论上的的模式是什么。

一个良好开始的第一原则——了解需求，并建立一个简单明了的解决方案以满足他们。如果你这样做了会使用到一些模式而你并不知道。在这个时候，你最好了解基本的架构和设计模式，这样你会从模式中找到一个解决方案，避免做重复的劳动。说起来容易做起来难，因为这是一个反复，并常常涉及到耐心、决心、勇气，并愿意不断学习的过程。

通过实际的讲解，本节将帮助你零起步。

回到基础

当使用到用户界面时，MVC是最唯一也是最重要的一种设计模式，所以我们从它开始。MVC模式由三个元素组成——model、view、和 controller。model是保存数据和状态的，view是用来看和交互的，controller是用户操作之后更新model的。

每一种模式是用一个已知的方式去解决一个重复的问题。如果你一直认为的model和view是一个紧密耦合单元，那么MVC能解决这个问题。如果model和view在同一个类中，那么它们紧耦合的，model中一个很小的修改会导致view中做大量的修改，如果有两个或更多的view要使用同一个model，会导致model会重复定义。这会导致矛盾和维护问题影响程序的进度。为同一个model增加一个新的view增加了障碍。

因此，MVC的第一个原则是保持view和model的相互独立。事实上model是完全不知道view的，model提供数据（状态）的访问接口并发布改变消息，view去使用它。为了实现这个目标，model的元素、状态和状态的逻辑改变时，model定义的应用程序接口（API）保持不变。这并不意味意API是静态的。这意味着修改一个重载或增加一个新函数支持新的参数和数据类型。也意味着你现有的接口保持不变。想要view了解model，你还需要一个中介来控制一个model实例。

一个典型的view允许使用者去创建、读、更新并删除model元素。读是一个最简单的操作，这个操作可以获得model的所有东西。对于创建，更新并且删除，view需要修改model元素，而且大多数情况下影响model的状态。这个时候我们需要controller。controller是一个中介，在用户操作后更新model(或其它的view)。一个controller可还有作为第三方管理多个view绑定一个model。

controller可以和view写在一个类或分开写成多个类。根据经验，除了最简单的情况下，其它的都应该写成分开的多个类。在简单的情况下，当view和controller一起在一个类时，模式经常称文档视图（Document View）模式。

下节继续!

(转载请注明出处,请勿使用商业用途!)