我已经用通常的 MVC 思维方式完成了大量的（网络）开发，我认为它对我很有帮助。
但是，我现在必须以前端必须将服务器端功能作为服务访问的方式拆分应用程序。
由于我是创建服务的人，因此我认为可以将服务视为控制器，而控制器又会调用模型中的函数。
这是一个好方法吗？
谢谢
P.S.：所讨论的服务器端技术是 PHP，客户端技术是 Adobe Flex (ActionScript)。
I've done a fair amount of (web)development in the usual MVC way of thinking and it served me well I think.
However, I now have to split my application in a way that my front-end has to access the server-side functions as services.
Since I'm the one creating the services, I thought I could think of services as controllers which would, in turn, call the functions in my model.
Is that a good way to do it?
Thank you
P.S.: The server side techonology in question is PHP and the client-side is Adobe Flex (ActionScript).
发布评论
评论（2）
有很多不同的方法，我不能说其中任何一个都是错误的。我想知道你目前的做法是什么；以及哪些限制让您想要改变它。
您似乎建议的方法是创建一个位于模型之间的外观（又名PHP代码）完成“繁重的后端提升”）和视图（又称为 Flex 前端）。我对此没有继承问题；特别是如果您已经实现了包含所有繁重工作/业务逻辑的后端。我会认为这个外观层是一个服务层，并且会认为它是模型的一部分；不是控制器的一部分。
当尝试在 Flex 和某些后端之间创建模型-视图-控制器-服务 (MVCS) 架构时；我通常这样做：
视图作为 Flex 组件实现。
控制器作为 ActionScript 类实现。从我的角度来看，控制器的主要目的是将请求转移到服务器并将数据返回到视图。
Service层是在服务器端实现的； PHP 在你的情况下。对于服务器端的每项服务，Flex 中可能有一个并行服务类。
模型层有类来执行相关的业务逻辑；验证数据、将其保存到数据库、从数据库检索数据，以及您需要的任何其他业务逻辑。通常，作为模型的一部分，我有值对象类。值对象类通常在 ActionScript 中并行，用于在服务器端服务和客户端控制器之间传输数据。
因此，它的工作原理如下：
有很多框架可以提供帮助这个过程，特别是对于应用程序各层之间的“封装”通信。
在许多情况下； “模型中应该包含什么/视图中应该包含什么”之间的界限是模糊的。当我们开发 Flex（或 AJAX、Silverlight 或任何智能客户端）应用程序时，我们通常希望拥有智能视图；因此一些业务逻辑可能会作为视图的一部分来实现。没关系;我们必须平衡应用程序的功能与“理想”的抽象案例。
你的问题有点宽泛，但我希望这会有所帮助。就我个人而言，我更喜欢实用的应用程序架构。有时我的服务类执行业务逻辑，例如数据解析。这取决于应用程序及其目标以及客户和时间框架。
There are a ton of different approaches, and I can't say any of them are wrong. I'm wondering what is your current approach; and what the limitation are that make you want to change it.
The approach you seem to be suggesting is to create a facade that stands between the model (AKA PHP Code that does the 'heavy backend lifting') and the view (AKA the Flex Front end). I don't have an inherit problem with that; especially if you already have a backend implemented that contains all the heavy lifting/business logic. I would consider this facade layer a service layer and would consider it part of the model; not part of the controller.
When trying to create an Model-View-Controller-Services (MVCS) architecture between Flex and some backend; I generally do it this way:
The views are implemented as Flex Components.
The Controller is implemented as an ActionScript class. From my perspective, the controller's main purpose is to shuffle requests to the server and data back to the views.
The Service Layer is implemented on the server; PHP in your case. It may be that you have a parallel service class in Flex for each services you have on the server side.
The Model Layer has classes to perform relevant business logic; to validate data to save it to a database to retrieve it from a database, and whatever other business logic you need. Often as part of the Model I have Value Object classes. Value Object classes are often paralleled in ActionScript and are used for transfer of data between the server side service and the client side controller.
So, it kind of works like this:
There are a lot of frameworks out there to help this process, especially for "encapsulated" communication between layers of the application.
In many cases; the line between "what should go in the model / what should go in the view" is blurred. When we're developing Flex (or AJAX or Silverlight or any smart client) applications, often we want to have smart views; so some business logic may get implemented as part of the view. That's fine; we have to balance the functionality of the app with an "ideal" abstraction case.
Your question was a bit broad, but I hope this helps. I, personally, prefer to be practical about my application architecture. Sometimes my service classes perform business logic, such as data parsing. It depends on the app and it's goals and the client and the time frame.
如果您的目标是在将服务中的数据返回到想要使用它的应用程序之前对其进行处理，您可以考虑创建一个 装饰器类为您服务。
下面是一个小图表，说明了检索帖子的服务的含义：
（好像不让发图片，所以我把它放在 ImageShack< /a>.)
PostService 类保存 RemoteObject 的一个实例，基本上只是远程 (php) 服务的客户端存根。它将向 onResult 或 onFault 函数返回 ResultEvent 或FaultEvent。
现在您可以创建一个实现相同接口的装饰器类。我将其命名为 PostServiceDecorator，但您最好给它起一个名称，以便您了解它到底执行什么处理。此类又包含 PostService 的一个实例。 PostService 会将 ResultEvent 传递给由 PostServiceDecorator 作为参数传递的函数，后者现在可以处理该事件并将（例如）post 对象的 ArrayCollection 传递给给定的 onResult 函数。
通过这种方式，您可以将事物分开：PostService 除了检索原始数据之外什么也不做，如果您不装饰它，仍然可以这样使用它。
但我知道有一个警告：这不是正确意义上的装饰器模式，因为您不能在使用它的代码中用一个 PostServiceDecorator 替换 PostService。它们将不同的对象传递给回调，因此如果您替换它们，您的代码将会中断。该接口只是强制您实现两个类中的所有方法。
If what you're aiming for is processing the data from the service before it is returned to the application that wants to use it, you might consider creating a decorator class for your service.
Here's a little diagram of what I mean with a service that retrieves posts:
(I seem not to be allowed to post images, so I put it on ImageShack.)
The PostService class holds an instance of the RemoteObject and is basically just a client side stub for your remote (php) service. It will return a ResultEvent or a FaultEvent to the onResult or onFault Functions.
Now you can create a decorator class that implements the same interface. I named it PostServiceDecorator, but you'd better give it a name that gives you an idea of what processing it does exactly. This class in turn holds an instance of your PostService. PostService will pass a ResultEvent to the function passed as an argument by PostServiceDecorator and the latter can now process that event and pass - say - an ArrayCollection of post objects to the onResult function that it was given.
This way you keep things separated: PostService does nothing but retrieving raw data an can still be used as such if you don't decorate it.
There is one caveat that I'm aware of though: this is not a decorator pattern in the proper sense, since you couldn't just substitute one PostServiceDecorator for PostService in the code that uses it. They pass different objects to the callbacks, so your code will break if you substitute them. The interface merely forces you to implement all the methods in both classes.