KleeneStar 0.0.1-alpha – A Flexible Data Model with Entity Framework

The development of KleeneStar began with a simple file‑based data storage system that was entirely sufficient for the early phase of UI development. As long as the focus remained on the user interface, this approach proved to be pragmatic and efficient. At the same time, the principle of persistent data storage was a central part of KleeneStar’s architecture from the very beginning, even if it remained intentionally in the background during the initial stages.

A platform like KleeneStar, designed to be modular, open, and extensible in the long term, requires a storage architecture that can reliably support these ambitions. As the feature set grew and the Workspace component became increasingly important, the question of flexible and sustainable data management moved steadily into focus.

This evolution led to the consideration of how to design a data model that is not tied to a single database but remains open enough to support different storage technologies in parallel. The goal was to create a solution that is both technically well structured and future‑proof, capable of meeting the diverse requirements of a modern platform.

Introducing a relational database as a persistent storage layer was a logical step. Entity Framework was chosen as the abstraction layer because it integrates seamlessly with KleeneStar’s existing concepts and enables a model‑oriented workflow. At the same time, the system should not be bound to a specific ORM or a single database. This led to the creation of KleeneStar.Model, a standalone .NET module that unifies multiple databases under a shared architectural framework and forms the foundation for future‑ready data persistence.

At the core lies a clear separation between core logic and concrete implementations. The model remains fully platform‑independent and defines, through consistent interfaces, how data is read, written, and managed. This results in an architecture that is not only clean but also onboarding‑friendly, giving developers a straightforward entry point.

True flexibility emerges through the adapters. Each database has its own adapter that implements the shared interfaces and encapsulates the specific characteristics of its underlying technology. An EF Core adapter supports relational databases such as PostgreSQL or SQLite, while a Mongo adapter represents the world of document‑oriented storage. Even fast, ephemeral stores like Redis can be integrated without difficulty. Each adapter is a self‑contained module, clearly separated, easy to test, and fully interchangeable. New databases can be added without modifying existing code, which aligns perfectly with the philosophy of KleeneStar.

For the development of KleeneStar, SQLite was chosen as the default provider because it is lightweight and well suited for local development environments. At the same time, the architecture remains open to additional providers contributed by the community. This creates an ecosystem that can adapt to different use cases and reflects the core values of KleeneStar: openness, modularity, and the willingness to adapt to diverse environments.

Because KleeneStar thrives as an open platform that grows and evolves, community involvement is a crucial factor. Anyone interested in developing new database adapters, improving existing modules, or contributing their own ideas is warmly invited to participate. Every extension, every discussion, and every contribution helps make KleeneStar an even more versatile and powerful platform. The architecture is intentionally designed so that new contributors can get started quickly and see their work make a real impact. Anyone who wants to be part of this journey will find in KleeneStar a project that not only promises openness but actively lives it.