-
Notifications
You must be signed in to change notification settings - Fork 97
Getting started
This is a description of the Quicksilver architecture. The Quicksilver sample site is intended as a reference architecture. The text describes the intended project structure, however some work still remains in parts of the project.
We have separated the features of this site into semi-independent parts. The main purpose of keeping feature-related code grouped together, is to get a sense of what constitutes a feature, and it usually helps to have related code close by. Ideally, you should be able to treat each feature as an isolated part of the site, so that it can be easily replaced and removed. However, in reality code is shared and dependencies may exist. Therefore, shared code is typically stored under Features/Shared. A typical feature often consists of one or more of these parts: controllers, pages, services, extensions, viewmodels, and viewmodel factories.
This is where everything needed to initialize and run the site is located. Things like service container configuration, site configuration, data import, and generally anything feature-agnostic is here.
The purpose of the tests is to demonstrate how different parts can be tested, but most importantly, provide a base on which to quickly expand the test suite when needed. And of course we wrote tests for our own sake, to verify the correctness of the key parts of the site. We use Moq, XUnit, and FluentAssertions. The structure of the test project follows the structure of the site, in terms of namespaces and features, which should make locating tests easier.
controller - we see a controller as something that controls the flow of http requests and also performs validation on the incoming requests. The rest is done outside of the controller, in the service layer.
service - a class that performs various tasks such as talking to the backend and database, and also contain helper methods. We try to keep controllers thin and ofload as much processing as possible to services.
viewmodel - used to render views. Often these are not used exclusively in views but also in the service layer.
viewmodel factory - These can be considered a type of service, or at least something that belong in the service layer. They are responsible for constructing viewmodels.