Design Principles
Lynicon has been built to follow a series of design principles to make it an excellent tool for professional content management.
Content Management as Facility not Platform: Its a tool, not a box
Lynicon is not a platform, or 'box' in which to put things, in the sense that most CMSs are. ASP.Net Core remains the platform on which you are building your site, and Lynicon does not interfere with that or stop you doing anything in the normal MVC way. This means since Lynicon is a tool, you can add it to an existing ASP.Net Core project, use it to only provide content management to a subset of pages, you can even use Lynicon as an editor frontend for existing database tables.
Don't Hijack the Platform's Extensibility
An essential part of allowing Lynicon to be retrofitted to an existing ASP.Net Core site is that it does not rely on any of the extension points by, for instance, changing any of the default service classes like model binding, view engine, etc. and so therefore it will not break any usage by a client application of these extension points.
Maximum Flexibility
Lynicon has a lot of deep powerful extension points designed to allow its functioning to be adapted as required by its own and third party modules, with systems to optimise the functioning of these extensions together. Modularity goes deeper in Lynicon than most CMSs, different caching methods can be added with switchable modules, and modules can be used to create versioning systems e.g. publishing.
Keep Things in Code that Should be in Code
Lynicon minimises the amount of web interface and leaves all functions that should not be accessed by editors and non-technical administrators in code. This means more effort can be spent in useful areas, ensures that accidental access is not given to powerful functions, and means that more changes can be managed by whatever code versioning system you use. It also greatly simplifies the management of changes in the content data, and the propagation of these changes across systems and servers.
Efficiency as a Primary Goal
Many CMSs which store data in databases do not as a fundamental design principle avoid unnecessary database accesses, then rely on caching systems to deal with the resulting inefficiencies. Novel architectural features in Lynicon mean that with the most commonly used cache in place, only one key-based single table database access should be required to render a page. Even without any caching, it should be possible to render a page with 2 database accesses retrieving multiple records by key.
Powerful but Simple Core Functions
Lynicon focuses on solving the hard problems cleanly and effectively leaving you to build the things you would want complete control over anyway. In a professional context, you want to be able to build something which exactly matches your or your client's requirements, and generally the boilerplate add-ons CMSs typically have are simply useless, and just clutter things up. A small but essential change in requirements may be unfulfillable because the half-heartedly designed module you used to solve the problem 'quickly' can't deal with it.
Lynicon's areas of focus include, providing you with very flexible content data structures, having a very powerful and flexible API for accessing content data, making the data editor at the same time powerful, easy to use for editors, and flexible, having comprehesive top quality tools for managing and deploying content data.
Don't Reinvent the Wheel
Lynicon lets you use your existing platform skills by avoiding the tendency of CMSs to rebuild features their platforms already do perfectly well. This allows the work taken to build Lynicon to be focussed in areas that are actually useful. For instance, it has no 'web part' system as ASP.Net Core already has all the tools you need to reuse elements of presentation, and actually does this much better than most of the other options. It doesn't have its own system for building content types, you simply use standard .Net classes (with a few limitations) and it does the rest.