How Dancing Goat web application works
The Mvc repository contains a sample web application Dancing Goat that demonstrates features related to MVC development support.
The MVC demo site, Dancing Goat, is built to showcase the usage of Kentico features when developing your MVC applications. Below you can find the reasoning behind some of the decisions made when building the Dancing Goat demo site.
The ASP.NET MVC development model in Kentico is based on a completely different approach when compared to developing websites using the Portal engine. The ASP.NET MVC application runs separately from Kentico and represents the presentation layer of your site. Kentico application represents the administration interface for content. Both applications connect to the same SQL database and use Kentico API calls when asking for data from the database.
The two applications run separately (ideally assigned different Application Pools in IIS). This means that the MVC application doesn't interfere with the Kentico application. In addition, the release cycle for Kentico MVC NuGet packages is independent of Kentico CMS.
The primary reason for the separation was to make the MVC development easier for the developer. MVC developers don't need to be familiar with the process of building websites in Kentico CMS. They can continue to develop the ASP.NET MVC site the way they are used to. This includes using all their favorite tools and libraries.
In order to make API calls to Kentico database, the MVC project has to reference the Kentico CMS libraries. The main Kentico.Web.Mvc NuGet package provides references to Kentico API which allows manipulation with the site's data. The other required NuGet package, Kentico.Libraries, contains the majority of the libraries used by the Kentico application itself.
Since the Kentico.Libraries package is meant for a variety external applications, some of the provided libraries may not be supported for MVC development. See Supported and unsupported Kentico features on MVC sites page for more details.
Content synchronization (including the smart search indexes) between the two applications is handled by the Web farm functionality in Kentico. Each application represents a web farm server. We recommend using the Automatic Web farm mode. For more information about setting up web farm servers, see the Configuring web farm servers page in the Kentico documentation.
Content only pages in Kentico give content editors control over a part of a page URL called page alias (also known as SLUG). This part of a URL identifies a page using human-readable keywords. Page alias should not be used as the only page identifier when displaying a page. The recommended practice for identifying pages that use page aliases is to use URLs that consist of NodeID (the main identificator) and Page alias (the SLUG). This is mainly to ensure SEO in case the page alias of a page changes. Internally, page alias is the NodeAlias of the content only page.
You can find more details in the Kentico documentation on the Providing friendly URLs on MVC sites page. This includes information such identifying and retrieving pages based on a page alias.
CSS files are stored on the filesystem within the MVC project to make the development easier. This way you can use your favorite tools (such as LESS, SASS, grunt and so on) to manipulate with CSS files. You can also utilize the Microsoft web optimization package to bundle CSS files together and serve only one bigger CSS file. See Bundling and Minification on asp.net for more information.
In Kentico, you can store data in Pages, custom module classes, custom tables, or media libraries. Each comes with its own use case and offers a different set of features.
The Dancing Goat demo site stores data in Pages because it offers the following features:
- You can display pages in Preview mode in the Pages application without going directly to the live site.
- You can use page field attachments.
- You can add new language versions of pages.
- You can define life cycle of pages with Workflows.
- You can set Related pages.
All of these features are available out-of-the-box with Pages.
Content tree structure defined in the Pages application doesn't correspond with site structure you see on the live site. Data in the content tree is saved in flat structure. The Dancing Goat demo site works with pages based on their individual page types instead of explicitly specifying their path. Such design leads to better performance because matching a page type is less expensive than matching a page path ( = vs LIKE '/path/%').
Since the data storage is managed by Pages, attachments are stored in page type fields. The Kentico API for field attachments has been improved and is strongly typed. Page attachments can be displayed in a View by using the following code:
<img src="@Url.Kentico().Attachment(Model.Fields.Teaser)" />
The Dancing Goat demo site contains the Repositories folder, which consists of repository interfaces (e.g. IAboutUsRepository.cs) and their implementations (e.g. KenticoAboutUsRepository.cs). This repository pattern helps create a level of abstraction for the data the MVC application works with. Its purpose is to reduce the complexity and expose only a limited set of methods required in the demo site. With such design, the demo site can communicate with the Kentico database by using a simple interface.
- It provides a concrete data interface for the MVC application.
- Writing unit tests for controllers is much easier. You are able to swap the default repository implementation with a fake repository implementation, which does not communicate with a database.
- You can use automated data caching for all repositories with the cooperation of the DI container (see Dependency Injection below) using its InterfaceInterceptors feature.
During the creation of the Dancing Goat demo site, there were two main criteria for the MVC application. It needed to be decoupled and easily testable. This means that the MVC application has to consist of components that are autonomous and unaware of one another, which in turn makes them easier to unit test. The dependency injection (DI) design pattern, as an implementation of the Inversion of Control (IoC) pattern, is used in the MVC application in order to meet the requirements.
The MVC application uses the Autofac DI/IoC container for Microsoft .NET. Following are some of the reasons for its choice:
- It has a clean and simple core that can be easily extended.
- It contains a sufficient set of features for the purpose of the demo.
- It did well in performance tests.