The following article describes the differences between the two technologies, as well as the benefits you experience when using ASP.NET Core framework frontend. 

For more information, see Sitefinity ASP.NET Core CMS Framework for Cross Platform Development.

General comparison


Since traditional MVC development takes place in the CMS, when the frontend system is under heavy load, the whole application (CMS) scales. This means that while additional resources are allocated to the part that is under load, various other parts of the system are left unused.

Because the ASP.NET Core frontend is decoupled from the backend of Sitefinity CMS and functions as a separate application, it can scale up or down independently and faster than Sitefinity CMS on its own. Thus, the resources allocated for the ASP.NET Core frontend are much less.


Since MVC is built on ASP.NET Framework, it can only be hosted on the Windows OS. ASP.NET Frontend, however, the Renderer is built with ASP.NET Core and can be hosted on all supported platforms – Linux, Mac, as well. 


When using MVC-based pages, they are either compiled on demand or can be precompiled using the Sitefinity Precompiler tool. A change to the root template of the site triggers the compilation of multiple pages that inherit it.  With ASP.NET Core pages, there is no page compilation. Changes to the template do not result in time-consuming and CPU-intensive operations. 


Both MVC and ASP.NET Core use output cache for caching the output of the pages. 


When upgrading the ASP.NET Core frontend, you upgrade only a small number of packages, which go through a backward compatibility automation testing suite. Since the APIs that the ASP.NET Core frontend uses are restricted to content APIs, you upgrade with minimal breaking changes in the APIs. 

Development comparison 

Handle GET actions

The most straightforward approach for developing MVC widgets is by using MVC controllers. They may typically have a single Index method that handles the generic execution. Based on routing logic, they can handle various other actions.

This is convenient, but when several controllers on the page have multiple actions, you need to invest additional work to make them work together. You do this by implementing the HandleUnkownAction method.
For more information, see Best practices for implementing custom widgets » HandleUnknownAction.

In comparison, ASP.NET Core uses ViewComponents that have a single method – Invoke or InvokeAsync, which is executed only on GET requests. 

Because there is only a single method, there are no clashes between logics of individual ViewComponents. Each widget can respond to query string parameters separately. In addition, widgets can respond to URL segments, using a centralized logic for resolving segments, otherwise not resolved by Sitefinity CMS. 

For more information, see Shared data between widgets sample project » IRequestPreparation interface on Sitefinity GitHub repository.

Handle POST actions

The MVC frontend is built to handle POST actions, and this enables each controller to handle POST requests, for example form posts from the frontend of the application. The drawback to this is that when you have multiple widget controllers on the same page, there is no way to determine which one should handle the POST request.

On the other hand, ASP.NET Core does not handle POST actions, it only handles the GET requests for the page. Alternatives to handling post actions are:

  • Implementing a custom controller to submit data to.
  • Posting form data directly to Sitefinity CMS.
    For more information, see Create forms.
  • Posting data by directly creating Sitefinity content, using the content modules.

Designer development

Developing designers with MVC is achieved by using AngularJS-based designers.
For more information, see Widget designers (MVC). The properties that are defined in the Controller or Model classes are then populated with those values.

In Sitefinity ASP.NET Core Renderer, widget designers we use automatically generated.
For more information, see Widget designers (ASP.NET Core)
Their benefit is that you do not need to consider the client frameworks, such as AngularJS. The properties of the widgets are placed in an Entity class, and they are decorated with meta-attributes. The meta-attributes control the visual representation of the designers.


Querying content items with MVC is done by using the C# APIs – the Native API and the Fluent API.

In addition, you can access system APIs. There is no limitation to the APIs, because the MVC frontend is in the same application as Sitefinity CMS itself.

With the ASP.NET Core framework, the available APIs are only the content APIs, served through the OData REST services. 
For more information about querying content, see REST SDK on Sitefinity GitHub repository.

Frontend frameworks

Both MVC and ASP.NET Core frameworks use the Bootstrap framework for building a mobile-friendly frontend. 
For more information, see Client-side development » JS frameworks and CSS frameworks.

Reference source for built-in widgets

As with the MVC widgets, the ASP.NET Core widgets are publicly available in Built-in ASP.NET Core widgets on Sitefinity GitHub repository.

Increase your Sitefinity skills by signing up for our free trainings. Get Sitefinity-certified at Progress Education Community to boost your credentials.

Get started with Integration Hub | Sitefinity Cloud | Sitefinity SaaS

This free lesson teaches administrators, marketers, and other business professionals how to use the Integration hub service to create automated workflows between Sitefinity and other business systems.

Web Security for Sitefinity Administrators

This free lesson teaches administrators the basics about protecting yor Sitefinity instance and its sites from external threats. Configure HTTPS, SSL, allow lists for trusted sites, and cookie security, among others.

Foundations of Sitefinity ASP.NET Core Development

The free on-demand video course teaches developers how to use Sitefinity .NET Core and leverage its decoupled architecture and new way of coding against the platform.

Was this article helpful?