接口 Controller

所有超级接口:
HttpRequestHandler
所有已知实现类:
AbstractController, AbstractUrlViewController, ParameterizableViewController, ServletForwardingController, ServletWrappingController, UrlFilenameViewController
函数接口:
这是一个函数接口, 因此可用作 lambda 表达式或方法引用的赋值目标。

@FunctionalInterface public interface Controller extends HttpRequestHandler
Base Controller interface, representing a component that receives RequestContext instances just like a HttpServlet but is able to participate in an MVC workflow. Controllers are comparable to the notion of a Struts Action.

Any implementation of the Controller interface should be a reusable, thread-safe class, capable of handling multiple HTTP requests throughout the lifecycle of an application. To be able to configure a Controller easily, Controller implementations are encouraged to be (and usually are) JavaBeans.

Workflow

After a DispatcherHandler has received a request and has done its work to resolve locales, themes, and suchlike, it then tries to resolve a Controller, using a HandlerMapping. When a Controller has been found to handle the request, the handleRequest method of the located Controller will be invoked; the located Controller is then responsible for handling the actual request and — if applicable — returning an appropriate Object result. So actually, this method is the main entry point for the DispatcherHandler which delegates requests to controllers.

So basically any direct implementation of the Controller interface just handles HttpRequests and should return a result, to be further interpreted by the DispatcherHandler. Any additional functionality such as optional validation, form handling, etc. should be obtained through extending AbstractController or one of its subclasses.

Notes on design and testing

The Controller interface is explicitly designed to operate on RequestContext objects, just like an HttpServlet. It does not aim to decouple itself from the Servlet API, in contrast to, for example, WebWork, JSF or Tapestry. Instead, the full power of the Servlet API is available, allowing Controllers to be general-purpose: a Controller is able to not only handle web user interface requests but also to process remoting protocols or to generate reports on demand.

Controllers can easily be tested by passing in mock objects for the RequestContext objects as parameters to the handleRequest method. As a convenience, Framework ships with a set of Servlet API mocks that are suitable for testing any kind of web components, but are particularly suitable for testing web controllers. In contrast to a Struts Action, there is no need to mock the ActionServlet or any other infrastructure; mocking RequestContext is sufficient.

If Controllers need to be aware of specific environment references, they can choose to implement specific awareness interfaces, just like any other bean in a Framework (web) application context can do, for example:

  • cn.taketoday.context.ApplicationContextAware
  • cn.taketoday.context.ResourceLoaderAware
  • cn.taketoday.web.servlet.ServletContextAware

Such environment references can easily be passed in testing environments, through the corresponding setters defined in the respective awareness interfaces. In general, it is recommended to keep the dependencies as minimal as possible: for example, if all you need is resource loading, implement ResourceLoaderAware only. Alternatively, derive from the ApplicationContextSupport base class, which gives you all those references through convenient accessors but requires an ApplicationContext reference on initialization.

从以下版本开始:
4.0
作者:
Rod Johnson, Juergen Hoeller, Harry Yang
另请参阅: