ASP.NET Core Razor pages vs Full MVC Core

asp.net-core-mvcrazor-pages

There has been a question at SO Why is Razor Pages the recommended approach to create a Web UI in Asp.net Core 2.0? where Steve Smith has kindly explained the benefits of using Razor Pages over full MVC from the perspective of having less files.

I've been using Razor Pages for a while and noticed that despite an advantage of a Razor Page simplicity, it is a bit complicated when it comes to custom routing, structuring folders and complex view model (page model seem to be cluttered).

So, the questions are:

If there is anything else except simplicity of a page to prefer Razor Pages over Controllers/Views – specifically I'm interested in performance of the two frameworks?
Is it acceptable to combine Razor Pages and Controllers/Views at the same time?

I would also appreciate if some of expirienced guys shared your thoughts (pros and cons) about using Razor Pages to better understand this framework.

Best Answer

We've recently launched a pretty decent sized app using Razor Pages for the front end and MVC controllers for the API for client side components. My experience has been this:

The pages paradigm works well when your content is structured around the idea of actual "pages" on the site. Think about things such as a Contact Us or an About or even a Login page. Sure, those could be done via MVC, but MVC is really unnecessary. A simple page will suffice. Leave the controllers to more controller'ish things like a product catalog or a user database.

If your MVC architecture revolves heavily around your view structure, razor pages is probably a good fit. You can still use the MVC bits for API related stuff, but the benefit of pages is that your front end structure becomes more explicit and less implicit ("convention-based") like with MVC where each action could or could not have a view that is typically named after the action.

Related Solutions

Windows – SWT application crashes in Windows 7

I have resolved this problem after asking the same question.

You must either remove SWT.VIRTUAL or update to the SVN build of SWT. I've posted a bug report on the SWT bug page.

Edit: your code snippet has a bug in it that is causing the ArrayIndexOutOfBoundsException. You can resolve it by changing lines containing listenerSD:

public void handleEvent(Event event) {
    Collection<?> collectionW = (Collection<?>) event.widget
            .getData(DATA_COLLECTION);
    if (collectionW.size() > event.index) {
        Object object = collectionW
                .toArray(new Object[collectionW.size()])[event.index];
        ((TableItem) event.item).setText(0, object
                .toString());
    }
}

C# – Resolving instances with ASP.NET Core DI from within ConfigureServices

The IServiceCollection interface is used for building a dependency injection container. After it's fully built, it gets composed to an IServiceProvider instance which you can use to resolve services. You can inject an IServiceProvider into any class. The IApplicationBuilder and HttpContext classes can provide the service provider as well, via their ApplicationServices or RequestServices properties respectively.

IServiceProvider defines a GetService(Type type) method to resolve a service:

var service = (IFooService)serviceProvider.GetService(typeof(IFooService));

There are also several convenience extension methods available, such as serviceProvider.GetService<IFooService>() (add a using for Microsoft.Extensions.DependencyInjection).

Resolving services inside the startup class

Injecting dependencies

The runtime's hosting service provider can inject certain services into the constructor of the Startup class, such as IConfiguration, IWebHostEnvironment (IHostingEnvironment in pre-3.0 versions), ILoggerFactory and IServiceProvider. Note that the latter is an instance built by the hosting layer and contains only the essential services for starting up an application.

The ConfigureServices() method does not allow injecting services, it only accepts an IServiceCollection argument. This makes sense because ConfigureServices() is where you register the services required by your application. However you can use services injected in the startup's constructor here, for example:

public Startup(IConfiguration configuration)
{
    Configuration = configuration;
}

public IConfiguration Configuration { get; }

public void ConfigureServices(IServiceCollection services)
{
    // Use Configuration here
}

Any services registered in ConfigureServices() can then be injected into the Configure() method; you can add an arbitrary number of services after the IApplicationBuilder parameter:

public void ConfigureServices(IServiceCollection services)
{
    services.AddScoped<IFooService>();
}

public void Configure(IApplicationBuilder app, IFooService fooService)
{
    fooService.Bar();
}

Manually resolving dependencies

If you need to manually resolve services, you should preferably use the ApplicationServices provided by IApplicationBuilder in the Configure() method:

public void Configure(IApplicationBuilder app)
{
    var serviceProvider = app.ApplicationServices;
    var hostingEnv = serviceProvider.GetService<IHostingEnvironment>();
}

It is possible to pass and directly use an IServiceProvider in the constructor of your Startup class, but as above this will contain a limited subset of services, and thus has limited utility:

public Startup(IServiceProvider serviceProvider)
{
    var hostingEnv = serviceProvider.GetService<IWebHostEnvironment>();
}

If you must resolve services in the ConfigureServices() method, a different approach is required. You can build an intermediate IServiceProvider from the IServiceCollection instance which contains the services which have been registered up to that point:

public void ConfigureServices(IServiceCollection services)
{
    services.AddSingleton<IFooService, FooService>();

    // Build the intermediate service provider
    var sp = services.BuildServiceProvider();

    // This will succeed.
    var fooService = sp.GetService<IFooService>();
    // This will fail (return null), as IBarService hasn't been registered yet.
    var barService = sp.GetService<IBarService>();
}

Please note: Generally you should avoid resolving services inside the ConfigureServices() method, as this is actually the place where you're configuring the application services. Sometimes you just need access to an IOptions<MyOptions> instance. You can accomplish this by binding the values from the IConfiguration instance to an instance of MyOptions (which is essentially what the options framework does):

public void ConfigureServices(IServiceCollection services)
{
    var myOptions = new MyOptions();
    Configuration.GetSection("SomeSection").Bind(myOptions);
}

Or use an overload for AddSingleton/AddScoped/AddTransient:

// Works for AddScoped and AddTransient as well
services.AddSingleton<IBarService>(sp =>
{
    var fooService = sp.GetRequiredService<IFooService>();
    return new BarService(fooService);
}

Manually resolving services (aka Service Locator) is generally considered an anti-pattern. While it has its use-cases (for frameworks and/or infrastructure layers), you should avoid it as much as possible.