Architecture

Lynicon unlike the vast majority of .Net content management systems, rather than giving you a prebuilt website scaffolding into which you add the various parts of your site, works by providing you with a library of features which you need to actively include to turn on content management functions.  The design principles section describes the aims of this.  Essentially, you configure certain routes to have content management, and turn on the modules you need to make that work how you want.

This is a very MVC approach to content management - simply the model is the content.

Lynicon has certain core areas of functionality which enable you to do this:

  • Routing: The routing system lets you automatically associate content data with each url mapped by the special DataRoute class.
  • Data API: The data system provides you with access to the content data, and is used by routing to retrieve the right data for each url.  A provider system allows you to use multiple different methods of storing content data, while allowing you to use type polymorphism across those data sources to retrieve and operate with similar kinds of data.  Linq is supported as a querying method.  Whole objects are stored allowing for inheritance, subobjects and lists in content item data.  You can point the data api at existing data sources and the CMS will automatically produce an editor for that data.
  • User Management: manages both content editor/admin users and site users.
  • Editors: when you are a logged in user with editing rights, and you go to a page with active content management, the routing system diverts you to a view of the page with an editor allowing you to edit the content data.  Different kinds of editors can be supported e.g. list based and single item based.  It's easy to build custom editors.
  • Modules: Extensions to Lynicon are built via modules, which can have their own UI, inject UI elements into the common UI, and make use of the Event System and Versioning.  Modules can also add fields to the types returned by the Data API for their own usage or add new database tables etc.
  • Event System: The different areas of Lynicon, particularly the Data API, fire global events that can be caught by modules to for instance, keep caches up to date as data is changed
  • Versioning: A generic versioning system supports any piece of content having multiple different versions, selecting the appropriate version for a given request.  Versioning is supported across all parts of the system.  Editors can switch versions where they are permitted to do so.