Data Types, Validation, and Enforcement in POCO DataSet

Descriptive vs Enforced Types

POCO DataSet intentionally does not enforce data types at the IDataRow cell level. Each cell stores values as “object?”, and assignments are not validated against column metadata at runtime. This design choice keeps the core data model lightweight, flexible, and suitable for dynamic schemas. For example:

dataRow["Age"] = "abc";   // Allowed at assignment time

Even if the column metadata declares the column as an integer type, the assignment itself succeeds.

Role of ColumnMetadata.DataType

The ColumnMetadata.DataType property is descriptive, not prescriptive. It serves as:

• a hint for UI rendering (e.g., which control to use)
• a documentation aid for developers
• optional input for adapters or validators

It is not automatically enforced by POCO DataSet core components.

The optional DataTypeNames class exists purely as a developer convenience to avoid magic strings when defining schemas. It does not imply runtime validation or database enforcement.

Where Type Enforcement Is Expected to Occur

POCO DataSet follows a layered responsibility model:

• UI layer - UI components (e.g., Blazor input controls) typically produce strongly typed values and prevent most invalid input.
• Business logic layer - Domain-specific validation rules are expected to live here (range checks, required fields, cross-field rules, etc.).
• Persistence layer (adapters) - Database providers may reject incompatible values during save operations if a value cannot be converted to the expected database type.

This mirrors how most enterprise applications are structured and avoids duplicating validation logic at multiple layers.

Persistence and Database Type Expectations

When persisting data:

• SQL adapters bind parameters primarily by parameter name and runtime CLR value type.
• Database type inference is typically performed by the provider (e.g., ADO.NET).

As a result:

• The actual value placed in a cell matters more than the DataType string.
• ColumnMetadata.DataType only influences persistence if an adapter explicitly uses it to configure parameters.

Why POCO DataSet Avoids ADO.NET-Style Enforcement

ADO.NET’s DataRow enforces types at assignment time, which:

• increases internal complexity,
• makes dynamic schemas harder,
• often duplicates business-layer validation.

POCO DataSet deliberately avoids this behavior to remain:

• flexible
• predictable
• suitable for dynamic UI generation and plugin-based architectures.

Future Extensions

Nothing in this design prevents adding:

• optional validation helpers
• pre-save validation pipelines
• adapter-specific type checks

These can be introduced without changing the core IDataRow behavior, preserving backward compatibility.

 

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.