Parsley 开发指南 10 构建模块化应用程序

本文详细介绍了如何使用Parsley构建模块化应用程序,包括模块上下文的使用、初始化方法、生命周期管理以及与Flex模块的集成。重点阐述了如何在大型应用中有效分割并按需加载模块,实现层次化的上下文管理,以及如何在不同ApplicationDomains之间共享上下文。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

10 构建模块化应用程序

Parsley允许你构建一个有层次的上下文,可以动态地加载和卸载。不管有没有使用Flex模块,这个层次可以创建,即使是纯AS3应用程序。对于Flex模块Parsley提供了一个额外的集成,它让它更容易处理多个不同的ApplicationDomains。

10.1 模块上下文

在大型应用程序中你可能想把应用程序分割成按需求加载的模块。在这种情况下,整个上下文在应用程序启动的时候加载和初始化这将是非常遗憾的。即使分割为多个文件的配置如 3.7组合多个配置机制 所示也不会有任何帮助。因为这些文件将会被合并成一个单一的上下文装载和初始化,就好像它是一个大型的配置文件。

这是Parsley的另一个方便的特性:当创建一个上下文的时候它可以连接到一个父上下文。父亲可能是加载应用程序的主上下文,子上下文可能是一个根据需求加载的模块需要的。子上下文的配置中你可以使用任何父上下文中依赖注入的对象(反过来不行)。消息还适用于穿过上下文边界,这你派发通过的作用域。你可以创建深度嵌套层次的上下文,但结构通常会变得很乏味,一个根上下文和任意数量的子上下文在同一级别。

有两种不同的方法来初始化一个子上下文:

10.1.1 连接一个上下文层次结构到视图层次结构

当你用ContextBuilder API指定一个视图根,或者当你使用引入MXML ContextBuilder标签自动把它上面的文档作为一个视图根,那么ViewManager 关联上下文将使用该视图根有两个目的:它将监听从希望得到连接到上下文的组件派发的冒泡事件,它将监听从视图层级中ContextBuilders 下面派发的冒泡事件。这样你就不必手动指定父上下文或ApplicationDomain,框架会帮你解决它:

<parsley:ContextBuilder config="{BookStoreConfig}"/>

或者

var viewRoot:DisplayObject = ...;

ContextBuilder

    .newSetup()

    .viewRoot(viewRoot)

    .newBuilder()

.config(FlexConfig.forClass(BookStoreConfig))

    .build();

在上面的例子中新的上下文将使用视图根自动寻找一个父上下文和监听在视图层次子上下文。在某些场景中,你可能会想保持上下文层次结构和视图层次分开。

10.1.2 手动设置一个父上下文

当你使用ContextBuilder API的时候,你可以定义一个现有的上下文作为一个新的上下文的父上下文。

var parent:Context = ...;

ContextBuilder

    .newSetup()

    .parent(parent)

    .newBuilder()

.config(FlexConfig.forClass(BookStoreConfig))

    .build();

在本例中我们没有指定一个视图根(注意,在本例中你不能动态连接视图到这个上下文),取而代之的是手动指定了一个父亲。你还必须知道的事实是,没有视图根上下文不能够自动检测到ApplicationDomain 来反射。所以如果你不在根ApplicationDomain 工作,而是在已加载的Flex模块的子域中,你也必须传递域到构建方法中。

var parent:Context = ...;

var domain:ApplicationDomain = ...;

ContextBuilder

    .newSetup()

    .parent(parent)

    .domain(domain)

    .newBuilder()

.config(FlexConfig.forClass(BookStoreConfig))

    .build();

当然这在指定视图根的时候不是必要的,因为构建器就能够自动检测父上下文和ApplicationDomain。

10.1.3 使用多个父上下文

这个特性是从2.4版引进的。在那之前上下文层次仅限于一个树结构,所以每个上下文可能有多个孩子,它总是只有一个父亲。指定多个父亲为创建上下文层次结构添加了更多的灵活性。例如,它可以建立一组库,可以相互依赖和连接他们相应的上下文。

我们假设你正在使用2个模块,可能需要由多个其他(否则不相关的)模块的应用程序,都有自己的上下文:

var messaging:Context = ...;

var persistence:Context = ...;

如果你构建另一个需要从消息和持久化注入的上下文,你可以指示ContextBuilder使用两个上下文作为父亲。

<parsley:ContextBuilder config="{BookStoreConfig}" parents="{[messaging persistence]}"/>

当使用ContextBuilderd 的时候它也会在视图层次中自动地寻找一个父亲。所以如果它找到一个父亲,那么就有三个父亲。你可以指示ContextBuilder不在层级结构中寻找父亲。

<parsley:ContextBuilder 

    config="{BookStoreConfig}" 

    parents="{[messaging persistence]}"

findParentInView="false"

/>

最后,当然ContextBuilder API也允许你使用此功能。你只需调用父方法多次:

ContextBuilder

    .newSetup()

    .viewRoot(viewRoot)

    .parent(messaging)

    .parent(persistence)

    .newBuilder()

.config(FlexConfig.forClass(BookStoreConfig))

.build();

上下文依赖查找优先级

当一个上下文查找一个依赖项,它首先会查找如果它发现它自己中的定义。如果没有成功,他会开始在父亲中一个接一个的找。顺序跟你指定构建上下文是相同的。当还有一个自动在视图层级中发现的父亲的时候,它总是最后一个被查找的上下文。

当通过类型使用依赖注入(不指定一个id),依赖不能模糊是很重要的。意思就是一个上下文不应该有超过一个匹配类型的托管对象。不论其他上下文是否有匹配的类型,当在上下文发现第一个匹配的实例的时候,查找就在这个上下文停止了。

共享上下文的ApplicationDomains 

实际上一个共享上下文的唯一选择是存在于根ApplicationDomain中。如果你使用多个模块加载到同一个子ApplicationDomain中,不在根ApplicationDomain中,这些模块之间共享任何东西都变得非常困难。这是因为同级ApplicationDomains看不到对方的类定义。这也意味着,这样的一个共享模块一旦它被使用就不能卸载。当为非常大的应用程序规划最大内存消耗的时候这是很重要的。

根据需求加载和初始化共享上下文

2.4版本功能的介绍仅仅是开始。该版本增加了低级钩子(low-level hooks),在核心API可以构建一个灵活的上下文层次结构,每个上下文可以有多个父亲。如你看到上面给出的例子,你仍然需要自己管理这些共享上下文。所以你应用程序的责任是知道哪个父亲被哪一个上下文需要,以及如何获取和构建这些上下文实例。所以对于一个非常大的应用程序,你很可能在现有Parsley特性上仍然建立某种程度的基础设施。

在将来(发布Parsley 3.0后的某个时间),将会有一个单独的Parsley扩展项目,该项目建立在此之上。它将允许你在一个简单的XML清单中指定共享上下文,框架将加载和初始化父亲当第一次需要他们的时候。

10.2 上下文生命周期

如果你加载多个上下文实例作为模块就像在前面部分中描述的,当你卸载模块的时候你可能想要摆脱他们——而不影响父亲。实际上这是这是很容易的,这样做就是:

context.destroy();

当连接一个上下文层次结构到视图层次结构中甚至更容易了。你不必显式地销毁上下文,当最后一个上下文关联的视图根从舞台被删除的时候,它会自动摧毁。 这是ViewManager的默认行为,可以修改如果你不希望上下文的生命周期取决于视图在舞台上存在的时间。你随时可以使用ViewManagerFactory的属性调整。

当一个上下文被摧毁了发生以下动作:

l 所有配置在被销毁的上下文中的对象都会停止接受Parsley中央MessageRouter派发的消息。这影响到所有用MessageHandler,MessageBinding,CommandResult 等等注解的的元素。

l 如果任何声明在被销毁的上下文中的对象声明了ManagedEvents ,他们从现在起会被忽略,不再通过Parsleys 消息传递系统派发。

l 在被销毁上下文中的任何对象中所有用[Destroy] 注解的方法(或相应的MXML或者XML标签)都会得到调用

l 损毁的上下文将删除所有配置对象的内部引用,所以他们有资格获得垃圾收集。(当然,你必须确保你的应用程序不保留任何这些对象的引用)。

l 调用销毁后上下文可能不再使用了。这个上下文上任何后续的方法再调用都会抛出错误。被销毁上下文的父亲(如果有的话)不会受到影响,并且可能继续正常运行。

10.3 使用Flex模块

在版本2.0.x中框架提供了一个特定的ContextModule MXML标签来指定模块的配置。这不再需要了,框架指定ContextModule和ModuleLoader标签已经被删除了。取而代之的是完全透明的支持了Flex 模块。使用常规的Flex ModuleLoader标签或者Flex ModuleManager加载模块。然后你可以在模块内部的任何地方创建子上下文,它并不会发生在根模块组件中。如果你连接上下文层次结构到视图层次结构就像它并不会发生在根模块组件,子上下文将自动确定父上下文和模块的ApplicationDomain 。

内容概要:本文档详细介绍了基于Python的在线二手电子产品回收系统的设计与实现。项目旨在通过构建一个可靠、安全、透明的平台,提高废旧电子产品的回收率,推动资源的合理再利用,提供安全可靠的交易平台,加强环保意识,促进二手市场的发展,并实现数据驱动的智能化服务。项目面临的主要挑战包括废旧电子产品的检测与评估、信息不对称与交易风险、市场需求的预测与定价、用户体验优化及平台的安全性与数据保护。解决方案涵盖智能化评估与回收定价、高效的二手产品处理流程、完善的售后保障体系、创新的市场需求分析、全程透明化与安全性保障以及定制化用户体验。系统采用微服务架构,包括用户管理、商品评估、交易管理、数据分析、支付与结算等模块。项目还涉及前端界面设计、API接口开发、数据库设计与实现、模型训练与优化、部署与应用等方面。 适合人群:具备一定编程基础,特别是对Python和Web开发有一定了解的研发人员,以及对二手电子产品回收和环保事业感兴趣的从业者。 使用场景及目标:①帮助用户方便地将闲置电子产品回收、交易或再利用,提高废旧电子产品的回收率;②通过智能化的数据分析为用户提供价格评估、市场需求分析等服务,提高回收效率;③提供安全可靠的交易平台,确保交易的公平性和安全性;④推动二手市场的健康发展,为消费者提供经济实惠的产品选择;⑤增强公众的环保意识,推动社会向绿色、低碳方向发展。 其他说明:本文档不仅提供了系统的功能模块设计、数据库表结构、API接口规范,还展示了具体代码实现和GUI界面设计,为开发者提供了全面的技术参考。此外,项目强调了数据安全和隐私保护的重要性,确保平台在运行过程中能够有效保护用户信息。项目未来改进方向包括增强模型的精准度、拓展国际市场、提供更多支付和融资选项、跨平台数据集成与分析、更加智能的回收流程以及强化社交化与社区功能。
内容概要:本文档详细介绍了基于C语言和单片机设计的固态继电器驱动空调温控系统,涵盖了从硬件电路设计、程序设计、GUI设计到代码详解的完整流程。项目旨在实现高效精准的温度控制、提升系统可靠性和寿命、灵活的参数设置和人机交互、降低能耗、模块化设计便于扩展与维护,以及促进智能家居与工业自动化发展。项目通过高精度温度采集与滤波算法、固态继电器驱动与保护电路设计、滞环控制算法、多层次软件模块化设计等创新点,确保系统的高效节能、智能化和高可靠性。; 适合人群:具备一定单片机和C语言编程基础的研发人员,尤其是从事嵌入式系统设计、智能家居和工业自动化领域的工程师。; 使用场景及目标:①实现高效精准的温度控制,确保室内温度维持在理想范围;②提升系统可靠性和寿命,减少故障率和维护成本;③支持灵活的参数设置和用户友好的人机交互界面,提升用户体验;④降低能耗,实现节能控制,推动绿色建筑和节能环保产业的发展;⑤通过模块化设计,便于后续功能升级和系统扩展,如远程监控、数据分析等智能化功能。; 其他说明:项目设计充分考虑了实际应用中的挑战,如温度采集的精度与稳定性、电气兼容性、系统响应速度与控制稳定性、软件设计的资源优化与抗干扰等,提出了针对性的解决方案。系统不仅适用于家庭智能空调,还能广泛应用于工业、商业建筑、医疗环境及农业温室等多个领域。未来改进方向包括智能温度预测与自适应控制、多传感器融合技术应用、远程监控与云平台集成、低功耗与绿色节能优化等。通过该系统,不仅能够精确控制室内温度,保障舒适环境,还能有效节能,延长设备使用寿命,具有重要的实际应用价值和推广意义。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值