To understand the RecroGrid Framework, it is useful to start from the world of classical UI component libraries such as DevExpress, MESCIUS, Syncfusion and Telerik. However, it is essential to recognize that the RecroGrid Framework operates at a higher level of abstraction as an integrated application platform that goes far beyond traditional component-library thinking.

Component libraries typically provide individual visual elements to developers – grids, form components, charts – which must be manually assembled, configured, bound to data sources, connected to APIs, and extended with authorization logic. Their documentation reflects this approach: it explains in detail how to initialize a specific grid, handle events, bind data sources, and implement validation.

With the RecroGrid Framework, the focus is fundamentally different.

Entity -> View as an Application Capability

From a component library perspective, a grid or form is a UI element that must be explicitly created and configured.

In the RecroGrid Framework, the primary building block is the entity.

Once a business entity is defined in the C#-based data model – for example using Entity Framework – the system interprets it as an application capability. The entity automatically provides:

• The list view
• The form view
• Corresponding API endpoints
• Built-in relation handling capabilities

The developer does not configure a grid component. Instead, they define a business object. Based on this definition, the RecroGrid Framework creates the complete, fully functional data management surface at runtime through intelligent abstraction – on both client and server sides.

This approach elevates the entity to an application-level unit rather than treating it as a simple data structure.

Architectural Relationship

In traditional component libraries, much of the behavior is implemented through declarative or imperative code. Grid behavior, column definitions, and editing modes typically appear in concrete, component-specific code blocks.

The RecroGrid Framework applies a metadata-driven, runtime-interpreted model.

• The data model and system configuration together act as metadata.
• The system interprets them at runtime.
• The UI and API layers are constructed consistently from the same underlying model.

As a result, application behavior can be shaped to a large extent through configuration – even in a production environment. Form layouts, field visibility, authorization rules, and grid settings can all be parameterized while the structural foundation remains stable.

For this reason, you will not find hundreds of lines of sample code demonstrating grid initialization in the documentation. In the RecroGrid Framework, such code is unnecessary. The grid is not an isolated UI component; it is a natural consequence of the entity-based application model. Once an entity is defined in the data model, its corresponding list view, form view, API endpoint, and relation management capabilities become immediately available in an integrated manner on both client and server sides.

Moreover, the functionality extends well beyond what is typically implied by component library documentation. The RecroGrid Framework natively provides field-level authorization, filtering and sorting on related entity fields within grid views, and persistence of user preferences including filters, sorting rules, column order, and other view parameters. These capabilities are intrinsic to the application model and are immediately available in a unified manner, delivering a significantly higher level of built-in intelligence than typical component-level implementations.

Code-Level Extension Points

A high level of automation does not imply loss of control.

Behind every generated behavior, the RecroGrid Framework provides well-defined C# extension points, including:

• Overridable methods
• Event handlers
• Service-layer extensions
• Validation and workflow hooks

The UI layer is architecturally decoupled from the core application model and can be replaced at the package level within the framework’s default operation.

At the same time, the layered client-side abstraction model allows fine-grained customization. Individual views, components, or even specific fields within a form can be overridden or extended with custom implementations without impacting the underlying domain model or server-side logic.

Application-specific customizations that directly depend on a particular UI implementation are naturally outside the scope of automatic portability; however, the RecroGrid Framework core remains strictly UI-agnostic and consistent in its runtime behavior.

Developers can:

• Customize individual components at code level
• Replace specific UI elements
• Integrate alternative UI libraries
• Implement a fully custom presentation layer

All while preserving the unified runtime behavior and the integrated client-server architecture of the RecroGrid Framework.

Developers do not work with component-specific UI APIs. Instead, they intervene using standard .NET and C# tools. Custom logic is implemented precisely where it is business-relevant, while the framework continues to ensure consistent, integrated operation.

This model:

• Eliminates repetitive, framework-specific boilerplate code
• Encourages clean domain-driven logic
• Improves long-term maintainability

Why the Documentation Follows a Different Logic

In a component library, documentation typically explains how to create a grid component, configure columns, handle events, bind data sources, and attach additional features.

In the RecroGrid Framework, this behavior is automatic. Therefore, the central questions of the documentation are:

• How to model the business entity
• How to configure behavior
• Where to extend the system with C# when custom functionality is required

The emphasis lies on the logic of the application model, the integrated client-server architecture, and the runtime automation mechanisms. The RecroGrid Framework elevates development to a higher level: instead of focusing on grid- and form-level technical details, the primary objective becomes the definition of business capabilities.

This shift in perspective is fundamental to understanding the system.

Next step