Description
Today, view compilers that implement IViewCompiler have two responsibilities. The first responsibility is view selection, which is to identify which view to return given a relative path. The second is view compilation, which is to perform any compilation steps needed to produce the view.
If we take a look at the DefaultViewCompiler, all of the work being performed in there is for view selection. The default compiler simply selects one of the pre-compiled views to return. Ironically, there is no view compilation being performed in this view compiler.
If we take a look at the RuntimeViewCompiler, it performs view selection of precompiled views, performs view selection of cshtml files on disk, performs view selection between competing precompiled views and cshtml files on disk, and then performs view compilation for cshtml files when they are selected. Again, most of the work happening in this compiler is actually for view selection.
With the compiler taking on both concerns, it is a burden when needing to override only one of these needs. For example, if you need to manipulate the way view selection is performed, you must provide a new implementation that performs both view selection and view compilation. Similarly, if you want to modify the way compilation is performed, you must also provide a new implementation for view selection.
I recommend that the IViewCompiler be split out into two different interfaces, one for each concern. This will allow each concern to be modified independently, and will give the types more appropriate names for the functionality they are responsible for.