Put points in the MVC Framework. Controller Factory
This chapter puts an end to the answer to the question “How and why does the controller factory work?”.
This is the third article in a series of articles about the internal structure of the MVC Framework . Summary of the previous parts: Should I switch to the MVC Framework? ; The mechanism of the MVC Framework: Part 1 and Part 2 . This article will focus on the controller factory mechanism, an important part of the MVC Framework, with which the entire framework begins.
A factory is the name of a design pattern that defines the mechanism for creating objects (class instances) without specifying the classes themselves. See the wiki for details. In the MVC Framework, the controller factory, as the name implies, is intended to create controller objects. Since the information about the required controller comes from the ASP.NET routing mechanism as a string with the class name, the controller factory builds controller objects based on this string.
Usually, a factory creates objects of classes, a specific interface. For the MVC Framework controller factory, this interface is IController . In general, the definition of the controller's interface factory looks like this:
A very simple interface: the CreateController method should return objects that implement IController, the ReleaseController should attend to removing the controller when the controller ceases to exist.
')
In order for the controller factory to return the required controller instance, parameters are passed to it as the name of the required controller controllerName and the requestContext request context that forms the ASP.NET routing mechanism. The ASP.NET MVC Framework developer does not need to write its own controller factory implementation, since the framework contains the default factory implementation. This implementation is the DefaultControllerFactory class .
When the ASP.NET MVC Framework engine receives a user request, the associated MvcRouteHandler handler processes it. Having found a suitable route, MvcRouteHandler calls the handler associated with the route. The default is MvcHandler , which both creates and uses a controller factory.
To obtain the controller factory class, MvcHandler uses the ControllerBuilder class (implemented as a singleton ), which always contains a field with an instance of the controller factory. By default, ControllerBuilder contains and returns an instance of the DefaultControllerFactory class. However, a developer can define his controller factory with simple code in global.asax :
where, the ControllerFactory is a custom controller factory class.
So, the controller factory, standard or user-defined is created. After that, it calls the CreateController method, which is passed the name of the controller class and the request context generated by the routing mechanism. Based on the data of these parameters, the factory must return an instance of the controller class or raise an exception.
In fact, redefining the controller factory is a completely optional step for creating MVC Framework projects. However, the developer can use the tool that controls the creation of controller classes.
The most common use case for its controller factory is to implement an IoC / DI container, such as Unity , to instantiate controller classes through the container. The need and need for an IoC / DI container is a topic for other articles, but if you use such containers in a project, redefining the controller factory can be a good way for you to create controllers through the container. A description of this implementation can be found in this article , here I will only give a class of custom controller factory created using Unity:
As you see, the new controller factory inherits from the DefaultControllerFactory and overloads the GetControllerInstance method, which is used in the DefaultControllerFactory to instantiate the controller class based on its type.
Another use of the controller factory can be the introduction of “black” and “white” lists for controllers that can or cannot be called up via client requests. This may make sense when creating a large project with a mass of controllers that can be decommissioned for a while. If you implement a factory of controllers that will be checked against black and white lists, then you can easily solve the problem of putting the controller out of use at the stage of its creation. Moreover, for this you will not need to either edit the code, create new routes, recompile assemblies, or restart the application. It will be enough to edit the “black” or “white” list, which can be represented even by an xml file.
We looked at how the controller factory works. It is important to learn the following:
This is the third article in a series of articles about the internal structure of the MVC Framework . Summary of the previous parts: Should I switch to the MVC Framework? ; The mechanism of the MVC Framework: Part 1 and Part 2 . This article will focus on the controller factory mechanism, an important part of the MVC Framework, with which the entire framework begins.Why the “factory”?
A factory is the name of a design pattern that defines the mechanism for creating objects (class instances) without specifying the classes themselves. See the wiki for details. In the MVC Framework, the controller factory, as the name implies, is intended to create controller objects. Since the information about the required controller comes from the ASP.NET routing mechanism as a string with the class name, the controller factory builds controller objects based on this string.
Controller Factory
Usually, a factory creates objects of classes, a specific interface. For the MVC Framework controller factory, this interface is IController . In general, the definition of the controller's interface factory looks like this:
public interface IControllerFactory {
IController CreateController(RequestContext requestContext, string controllerName);
void ReleaseController(IController controller);
}
* This source code was highlighted with Source Code Highlighter .A very simple interface: the CreateController method should return objects that implement IController, the ReleaseController should attend to removing the controller when the controller ceases to exist.
')
In order for the controller factory to return the required controller instance, parameters are passed to it as the name of the required controller controllerName and the requestContext request context that forms the ASP.NET routing mechanism. The ASP.NET MVC Framework developer does not need to write its own controller factory implementation, since the framework contains the default factory implementation. This implementation is the DefaultControllerFactory class .
DefaultControllerFactory
When the ASP.NET MVC Framework engine receives a user request, the associated MvcRouteHandler handler processes it. Having found a suitable route, MvcRouteHandler calls the handler associated with the route. The default is MvcHandler , which both creates and uses a controller factory.
To obtain the controller factory class, MvcHandler uses the ControllerBuilder class (implemented as a singleton ), which always contains a field with an instance of the controller factory. By default, ControllerBuilder contains and returns an instance of the DefaultControllerFactory class. However, a developer can define his controller factory with simple code in global.asax :
protected void Application_Start()
{
RegisterRoutes(RouteTable.Routes);
ControllerBuilder.Current.SetControllerFactory( new ControllerFactory());
}
* This source code was highlighted with Source Code Highlighter .where, the ControllerFactory is a custom controller factory class.
So, the controller factory, standard or user-defined is created. After that, it calls the CreateController method, which is passed the name of the controller class and the request context generated by the routing mechanism. Based on the data of these parameters, the factory must return an instance of the controller class or raise an exception.
When using a standard controller factory, in the context of a request, among other things, a set of route parameters RequestContext.RouteData.DataTokens can be passed, which can contain namespace names (using the value of the Namespaces parameter) in which the controller class should be searched. This can be useful and can speed up the application if there are a lot of namespaces in your project, and controllers are limited to only one. For details, look for a description of how to create routes.
Why and how to define your controller factory
In fact, redefining the controller factory is a completely optional step for creating MVC Framework projects. However, the developer can use the tool that controls the creation of controller classes.
The most common use case for its controller factory is to implement an IoC / DI container, such as Unity , to instantiate controller classes through the container. The need and need for an IoC / DI container is a topic for other articles, but if you use such containers in a project, redefining the controller factory can be a good way for you to create controllers through the container. A description of this implementation can be found in this article , here I will only give a class of custom controller factory created using Unity:
public class UnityControllerFactory : DefaultControllerFactory
{
IUnityContainer _container;
public UnityControllerFactory(IUnityContainer container)
{
_container = container;
}
protected override IController GetControllerInstance(Type controllerType)
{
if (controllerType == null )
throw new ArgumentNullException( "controllerType" );
if (! typeof (IController).IsAssignableFrom(controllerType))
throw new ArgumentException( string .Format(
"Type requested is not a controller: {0}" , controllerType.Name),
"controllerType" );
return _container.Resolve(controllerType) as IController;
}
}
* This source code was highlighted with Source Code Highlighter .As you see, the new controller factory inherits from the DefaultControllerFactory and overloads the GetControllerInstance method, which is used in the DefaultControllerFactory to instantiate the controller class based on its type.
Another use of the controller factory can be the introduction of “black” and “white” lists for controllers that can or cannot be called up via client requests. This may make sense when creating a large project with a mass of controllers that can be decommissioned for a while. If you implement a factory of controllers that will be checked against black and white lists, then you can easily solve the problem of putting the controller out of use at the stage of its creation. Moreover, for this you will not need to either edit the code, create new routes, recompile assemblies, or restart the application. It will be enough to edit the “black” or “white” list, which can be represented even by an xml file.
Point
We looked at how the controller factory works. It is important to learn the following:
- the controller factory is called from the routing mechanism;
- the controller factory creates instances of controller classes;
- You can override the factory of controllers, but this is completely optional;
- it is better to inherit your own copy of the controller factory from the DefaultControllerFactory base class in order not to disrupt the operation of the MVC Framework mechanism;
- if you are using IoC / DI containers, then the controller factory will help you a lot.
Source: https://habr.com/ru/post/64600/
All Articles