我已经用通常的MVC思维方式进行了相当多的（web）开发，我认为这对我很有帮助。
然而，我现在必须以一种方式拆分我的应用程序，即我的前端必须访问服务器端函数作为服务。
由于我是创建服务的人，我想我可以把服务看作控制器，反过来，控制器会调用我模型中的函数。
这样做好吗？
谢谢
附言：服务器端技术是PHP，客户端是AdobeFlex（ActionScript）。
有很多不同的方法，我不能说其中任何一种都是错误的。我想知道你目前的做法是什么；以及限制是什么让你想要改变它。
您似乎建议的方法是创建一个位于模型（又名PHP代码，用于"繁重的后端提升"）和视图（又名Flex前端）之间的外观。我对此没有继承问题；尤其是如果您已经实现了一个包含所有繁重工作/业务逻辑的后端。我会将这个门面层视为服务层，并将其视为模型的一部分；而不是控制器的一部分。
当试图在Flex和一些后端之间创建模型-视图-控制器服务（MVCS）体系结构时；我通常是这样做的：
这些视图被实现为Flex组件。
控制器被实现为ActionScript类。从我的角度来看，控制器的主要目的是将请求转移到服务器，并将数据返回到视图。
服务层是在服务器上实现的；PHP。对于服务器端的每个服务，您可能在Flex中都有一个并行服务类。
模型层具有执行相关业务逻辑的类；验证数据以将其保存到数据库中，从数据库中检索数据，以及您需要的任何其他业务逻辑。作为模型的一部分，我经常有Value Object类。Value Object类通常在ActionScript中并行，用于在服务器端服务和客户端控制器之间传输数据。
所以，它的工作原理是这样的：
- 用户与视图交互
- 视图将事件分派给控制器
- 控制器对服务器上的服务进行远程调用
- 服务调用模型以获取数据
- Model获取请求，执行适当的操作，创建一个值对象或值对象数组，并将其返回给服务
- 服务将结果返回给客户端控制器
- 控制器执行某些操作以更新视图
有很多框架可以帮助这个过程，特别是对于应用程序层之间的"封装"通信。
在许多情况下；"模型中应该包含什么/视图中应该包含哪些"之间的界限变得模糊。当我们开发Flex（或AJAX、Silverlight或任何智能客户端）应用程序时，我们通常希望拥有智能视图；因此，一些业务逻辑可以作为视图的一部分来实现。这很好；我们必须在应用程序的功能与"理想"抽象案例之间取得平衡。
你的问题有点宽泛，但我希望这能有所帮助。I、 就我个人而言，我更喜欢对我的应用程序体系结构进行实践。有时，我的服务类执行业务逻辑，例如数据解析。这取决于应用程序、目标、客户端和时间框架。
如果您的目标是在服务的数据返回到想要使用它的应用程序之前处理它，那么您可以考虑为您的服务创建一个decorator类。
以下是我对检索帖子的服务的理解：（我似乎不被允许发布图片，所以我把它放在ImageShack上。）
PostService类包含RemoteObject的一个实例，基本上只是远程（php）服务的客户端存根。它将向onResult或onFault函数返回ResultEvent或FaultEvent。
现在，您可以创建一个实现相同接口的decorator类。我把它命名为PostServiceDecorator，但你最好给它一个名字，让你知道它到底做了什么处理。这个类又持有PostService的一个实例。PostService将向PostServiceDecorator作为参数传递的函数传递ResultEvent，而后者现在可以处理该事件，并将post对象的ArrayCollection传递给它所给定的onResult函数。
这样你就可以把东西分开：PostService只检索原始数据，如果你不装饰它，它仍然可以使用
不过，我知道有一点需要注意：这不是一个正确意义上的装饰器模式，因为在使用它的代码中，你不能用一个PostServiceDecorator来代替PostService。它们将不同的对象传递给回调，所以如果你替换它们，你的代码将中断。接口只是强制您实现两个类中的所有方法。