Quino is a powerful, flexible, modular and modern metadata framework for building all kinds of applications with .NET — from lightweight API servers to SPA web apps to Winform or WPF on the desktop.
An application uses Quino to define, extend and use its domain model. A domain model consists of classes, properties, relations, layouts, indexes, methods and more.
The model-first approach, as opposed to a database-first or code-first approach, puts the focus on your application's domain model — where it belongs. Quino is implemented in .NET, but the concept — encapsulating application-domain knowledge — could be built in any language or runtime.
Quino is highly modular: the core consists of just three assemblies. The metadata itself is straightforward and easy to understand. It can be extended in myriad ways with appication-specific aspects that can be used by components that rely on Quino.
Other modules use metadata to provide other services:
When you use Quino, you define your metadata and choose the modules your application will use. A typical application will include a data driver (PostgreSql and SQL Server are supported) as well as automated schema migration. With a few lines in the configuration, the application gets a full CRUD client for the data model in either Winform or WPF.
Such an application can be used for extremely fast and streamlined prototyping. As well, the application can be extended without into production code directly.
Quino is for developers. Domain models are defined in a .NET language.1 The developer feedback loop is extremely tight: new parts of the model are available for use in tests and the UI with a quick rebuild and run.
The WPF and Web clients can be fully styled (the Winform client has more limited styling support). Customer-specific model elements are supported through plugins, which can be either .NET assemblies or C# source files (if enabled). This allows a lot of flexibility for custom fields and details.
What's wrong with the approach taken by Entity Framework (EF) or other ORMs that employ database-first or code-first approaches? It's clear that database-first has its place for applications that use legacy data. Quino provides that support, as well.
When defining a new application, however, it's better to build the model first. The advantages of this approach are:
What about the code-first approach? This approach defines tables as C# objects with attributes to define relationships, indexes and so on. Where that doesn't suffice, you can configure the model further with a fluent API (at least in EF).
However, much of this model is not available as code or is provided by EF with the express purpose of being used by an ORM. You can't extend EF's metadata to accommodate other purposes. If you do, you'll end up fighting with metadata whose intent is data-persistence, not a generalized domain-model description. Instead of an API focused on metadata-retrieval, you use a more generalized reflection API.
As mentioned above, Quino includes support for generated UIs with Winform and WPF targets. For web applications, you can integrate an OWIN server, running as a standalone executable or as a Windows service. There is a Quino web client written with React and Mobx.
The following examples show the Sandbox model included in Quino running in the various UIs.