Overview of the Data Model

The POCO DataSet data model is designed to provide a clean, predictable structure for working with tabular data in modern .NET applications. It is composed of independent but related layers, allowing data, schema, and metadata to be transported, displayed, or processed in a flexible and extensible way.

Core Concepts

• DataSet – is the top-level container for multiple DataTables. It provides named access, allowing applications to organize different logical tables within a single structure. It contains no hidden behavior and enforces no relations unless explicitly implemented.
• DataTable – represents a logical table. It defines both schema and data. Schema is represented by ColumnMetadata entries, while data is stored in DataRow objects. This model supports predictable, metadata-driven value access, making dynamic user interface rendering straightforward and predictable.
• DataRow – holds values for a single logical row. Its internal storage aligns with the table’s metadata, ensuring data integrity and predictable value access by column name.
• ColumnMetadata – defines the schema of a column within a DataTable. It contains structural information needed by both server-side logic and UI components, enabling metadata-driven data processing and dynamic form generation.

The model separates schema (ColumnMetadata) from data (DataRow) while linking them through the DataTable. This enables scenarios such as loading schema-only datasets, transporting data without schema, or mixing both depending on UI or service needs.

Supported Data Types

POCO DataSet supports a range of fundamental .NET types suitable for JSON serialization and dynamic UI rendering. All supported types are compatible with runtime metadata inspection and predictable roundtripping across application layers.

• All commonly used scalar .NET types - bool, DateTime, decimal, double, float, Guid, int, long, short, string
• Nullable types - every value type is supported in its nullable form. Nullability is controlled at the metadata level, enabling schemas to express optional or required values clearly.
  • If a column is marked nullable, DataRow may store null for that column.
  • If a column is non-nullable, DataRow must store a valid value.
  • UI components use this information for validation and control rendering.
  • Serialization preserves nulls exactly as declared.
• Enums - enumerations are supported as long as they can be represented in JSON. They are useful for dropdowns or limited-choice fields.

Primary Keys

POCO DataSet can store primary key information for rows, but it does not enforce it automatically. Primary keys exist to help your application identify rows when needed (for example, during updates or merges), but the framework does not impose constraints or hidden rules. How primary keys are used is always an explicit decision made by your application. For example, a primary key may be used during merge operations to match refreshed rows with existing client-side data.

Primary Key Characteristics:

• Primary keys can consist of one or more columns.
• They are defined through metadata or explicit application logic.
• They are used for row identity, comparison, or linking.
• No automatic constraint enforcement is performed internally.

This flexible model allows developers to define only the identity rules they need without inheriting complexity.

Relationships Between Tables

POCO DataSet does not enforce relationships between tables internally. Instead, it allows applications to define foreign keys, logical links, and other relationships based on their specific needs without rigid constraints. This approach maintains POCO DataSet’s lightweight philosophy. Applications can implement relationship behavior as needed, whether in service layers, UI components, or rule engines.

Types of Relationships:

• Foreign key relationships - represent classic parent–child relationships where one table references another using a key value (for example, Order.CustomerId - Customer.Id). In POCO DataSet, foreign keys are expressed as metadata and used by application logic for tasks such as validation, merging, or UI navigation, but they are not automatically enforced by the framework.
• Logical links (non-key references) - represent relationships that exist conceptually but are not based on formal keys. These links may reference business identifiers, codes, or contextual values (for example, linking records by status, category, or external identifiers). POCO DataSet allows such links to be described without assuming database-style constraints or referential enforcement.
• Natural keys - use meaningful business data to identify rows instead of surrogate IDs (for example, CountryCode, EmployeeNumber, or Email). POCO DataSet can record natural key intent in metadata, but it does not impose uniqueness or constraint rules — allowing applications to decide when and how natural identity matters.
• Lookup relationships - represent references to relatively static reference data, such as Department, Status, or Type tables. These relationships are commonly used for UI rendering (drop-downs, labels, value-to-text mapping) rather than strict data integrity. POCO DataSet treats lookup relationships as descriptive metadata rather than enforced relational rules.

Summary

Together, these concepts define POCO DataSet as a flexible, metadata-driven data model. The framework records structure and intent but leaves enforcement and behavior to application logic, keeping responsibilities explicit and predictable.

 

Table of Content POCO DataSet Concepts

 

---

Business Process Programming in .Net
© 2004–2026 Laskarzhevsky Software Inc.
Unless otherwise noted, the content of this website is licensed under the Creative Commons Attribution 4.0 International License (CC BY 4.0).
Code examples are provided under the MIT License.
You are free to share and adapt the material provided that appropriate credit is given and any modifications are clearly indicated.
The information provided on this website is for educational purposes only.
The author and publisher make no warranties regarding the completeness or suitability of the information and are not responsible for any damages resulting from its use.