PureMVC框架的既定目标之一是避免平台依赖性以便于移植。考虑到由于语言和API的差异，应用程序代码将始终严重依赖于平台，并且避免平台依赖关系会使框架重新发明轮子和/或者仅提供最小公分母功能集，以何种方式实现可移植性框架使我作为应用程序开发人员受益吗？

解决方案

我曾与PureMVC合作。他们正在尝试以多种语言来实现自己的东西。我们可能对最小公分母是正确的，但是总的来说，这并不是一个糟糕的框架，而且我在PureMVC中看到了一个非常不错的AS3应用程序。

我不认为他们是在移植实际代码方面谈论可移植性。有更多的想法是我们正在使用通用的MVC体系结构，可以将其应用于其他项目和其他语言。

他们试图说，如果我们熟悉PureMVC模式，即使它是另一种语言，也有可能进入新的PureMVC代码库，并且我们已经了解了这片土地。

我们可能还会说，具有良好PureMVC技能的开发人员可能会养成良好的习惯，这些习惯会随着语言的不同而转换。但是话又说回来，也许不是..由于我们提到的原因。

现在，我们已经在两个项目上使用了PureMVC，在我看来，独立于语言的尝试是相当大的负担。

如果语言已经不是很相似，那么因为框架已经知道而直接跳入项目的承诺似乎与我不相关(Cto Java会有意义，而as3与php则不一样)-我同意知道这很有用解决问题的方法，但为此，"简单"模式已经足够了。

但是，我也不太同意该项目使用的各种模式的用法，因此我们选择不在下一个项目中使用它可能与这两个问题有关，而不仅是与语言/平台独立性的尝试有关。

对于选择不使用Flex Framework的Flash Platform开发人员而言，PureMVC是唯一的真实选择。对于某些项目，Flex的大小成本太昂贵了(它确实发生了！)。

我喜欢在Flex中进行原型制作，然后将其剔除，并在应用程序即将完成时用自定义组件替换我的视图。 PureMVC的Mediator模式使其真正易于实现。我不确定是否有其他框架可以允许我进行此工作流程。

就我个人而言，我认为PureMVC在可移植性目标上做得太过分了：我喜欢它可以与Flash和Flex一起使用的事实(出于上述原因)，但我认为它应该在那里停止了，并利用了本机Flash Player事件建筑学。

当我们迁移到另一种语言或者以另一种语言重新实现时，PureMVC的可移植性将为我们提供帮助。

我无法数出我为此编写的平台和语言的数量已不复存在，即使我仍然拥有源代码，但对于它而言，它们几乎是一文不值，因此必须从今天起重新编写该代码通常是100％针对特定平台的。

但是，所有应用程序代码无需在很大程度上依赖于平台。视图组件和服务(应用程序的边界)必定是必需的，但是夹在边界之间的应用程序逻辑则不一定是必需的。

PureMVC的范围确实非常狭窄；仅仅是为了将代码分成MVC元模式所禁止的三层。没有理由必须将此代码与平台紧密联系以使其达到最佳状态。

当需要进行迁移时，我们会欣赏到框架参与者及其角色，职责和协作保持不变。这使我们可以处理语言的语法差异，从而重新创建视图组件和服务。至少我们不必完全重新架构。

对于以另一种语言重新实现的情况，请想象我们正在尝试通过应用程序占领移动市场的重要部分。市场是如此分散，我们必须在Windows Mobile，iPhone，Flash和Java的2个或者多个上实现相同的程序。当然，我们可能将有单独的团队负责这些应用程序，但是为什么要使用完全不同的体系结构？使用PureMVC，我们可以为所有版本的应用程序提供单一体系结构。

-=悬崖>

有没有人使用PureMVC在多个平台上构建和移植应用程序的例子？

我的公司正在构建一个Flex应用程序，我们可能需要将其移植到其他平台：

• Silverlight(可能)
• 移动(也许)
• 台式机(也许-不只是AIR！)
• 电视机(也许最终)

我正在考虑将PureMVC作为框架，如果它可以简化移植和维护。我很想知道其他人是否已将PureMVC应用程序移植到其他平台上，以及他们在移植然后在多个平台上并行进行该应用程序开发方面的经验。

干杯，

卡尔提克

PureMVC的内部工作(Flash事件等)不依赖平台。
因此，尽管它不能使说说变得容易些，但它可以通过向我们展示它友好而熟悉的面孔(无论我们选择去哪里)简单地提供帮助；-)