服务应该像控制器一样工作吗？

有很多不同的方法，我不能说其中任何一个都是错误的。我想知道您目前的做法是什么；以及您要更改它的限制是什么。 您似乎建议的方法是创建一个立在模型（AKA PHP代码执行“沉重的后端提升”）和视图（AKA Flex前端）之间的立面。我没有继承的问题；尤其是如果您已经实现了包含所有繁重的工作/业务逻辑的后端。我会将此外观层视为服务层，并将其视为模型的一部分；不是控制器的一部分。 尝试在Flex和某些后端之间创建模型视图控制器服务（MVCS）体系结构时；我通常是这样的： 这些视图被实现为Flex组件。 Controller作为ActionScript类实现。从我的角度来看，控制器的主要目的是将对服务器的请求和数据重新整理回视图。 服务层在服务器上实现；您的PHP。对于服务器端具有的每个服务，Flex中可能都有一个并行服务类。 模型层具有执行相关业务逻辑的类。验证数据以将其保存到数据库以从数据库中检索数据，以及所需的任何其他业务逻辑。通常作为模型的一部分，我有值对象类。值对象类通常在ActionScript中并行使用，并用于在服务器端服务和客户端控制器之间进行数据传输。 因此，它的工作方式如下： 用户与视图进行交互 该视图将事件调度到控制器 控制器对服务器上的服务进行远程调用 服务调用模型以获取数据 模型获取请求，执行适当的操作，创建一个值对象（或值对象数组），并将其返回给服务 服务将结果返回给客户端控制器 控制器执行某些操作以更新视图 有很多框架可以帮助完成此过程，尤其是对于应用程序各层之间的“封装”通信。 在许多情况下； “模型中应包含的内容/视图中应包含的内容”之间的界限是模糊的。当我们开发Flex（或AJAX或Silverlight或任何智能客户端）应用程序时，通常我们希望拥有智能视图。因此某些业务逻辑可能会作为视图的一部分实现。没关系;我们必须通过“理想”抽象案例来平衡应用程序的功能。 您的问题有点广泛，但我希望这会有所帮助。我个人更喜欢对我的应用程序体系结构进行实践。有时，我的服务类执行业务逻辑，例如数据解析。这取决于应用程序及其目标，客户和时间范围。     

如果目标是在将服务中的数据返回给要使用的应用程序之前对其进行处理，则可以考虑为服务创建一个装饰器类。 这是我对检索帖子的服务的含义的简要图示： （我似乎不被允许发布图像，因此将其放在ImageShack上。） PostService类包含RemoteObject的实例，并且基本上只是远程（php）服务的客户端存根。它将一个ResultEvent或FaultEvent返回到onResult或onFault函数。 现在，您可以创建实现相同接口的装饰器类。我将其命名为PostServiceDecorator，但最好给它起一个名字，让您知道它的确切处理方式。此类又包含PostService的一个实例。 PostService会将ResultEvent传递给PostServiceDecorator作为参数传递的函数，后者现在可以处理该事件，然后-将post对象的ArrayCollection传递给给定的onResult函数。 这样，您就可以将事情分开：PostService只会执行原始数据的检索，如果您不装饰原始数据，则仍然可以使用。 不过，我需要注意一个警告：这并不是正确的修饰器模式，因为您不能仅在使用它的代码中用PostServiceDecorator替换PostServiceDecorator。它们将不同的对象传递给回调，因此如果替换它们，代码将中断。该接口仅强制您在两个类中实现所有方法。