Why POCO Instead of System.Data?

POCO DataSet was created to address the limitations, complexity, and legacy behaviors found in the classic System.Data.DataSet. While System.Data served its purpose in early .NET applications, modern architectures — especially modular, metadata-driven, or UI dynamic systems — require a simpler, more predictable, and serialization friendly model. POCO DataSet delivers exactly that.

Key Reasons for Choosing POCO DataSet

1. Legacy Weight of System.Data.DataSet

System.Data.DataSet was designed in the early 2000s for drag drop WinForms data binding scenarios. It includes many implicit assumptions, hidden behaviors, and large feature sets that are rarely used in modern applications. Examples include relation graphs, constraints, XML centric serialization, and typed dataset generators.

POCO DataSet removes all of this complexity. It provides only what is essential: tables, rows, and columns, with clear metadata. Nothing more, nothing hidden.

2. JSON Serialization and Modern Web Compatibility

System.Data.DataSet was originally designed for XML serialization. JSON serialization of DataSet often produces verbose, awkward structures, and deserialization can be unreliable without custom converters.

POCO DataSet is JSON-first. Object graphs are simple, POCO-based, and free of circular references, making roundtripping through System.Text.Json or Newtonsoft.Json consistent and predictable.

3. POCO-Based Instead of Framework-Based

DataSet, DataTable, and DataRow in System.Data inherit from complex base classes with internal state machines. This makes them difficult to extend, mock, or integrate into modern dependency injection systems.

POCO DataSet uses plain C# classes behind simple interfaces. They are easy to mock, test, serialize, and customize. This is especially valuable in architectures like BPUA, where plugins exchange data through stable contracts.

4. Better for Dynamic UI Generation

System.Data.DataSet was never designed for dynamic UI rendering. While it technically contains schema information, that schema is tied to XML standards and does not translate well to modern UI frameworks.

POCO DataSet was explicitly designed for metadata-driven UIs. ColumnMetadata provides clear definitions of column names, types, nullability, and custom attributes—perfect for form, grid, and component generation in Blazor.

5. No Hidden Behaviors or Implicit Rules

System.Data.DataSet contains many automatic behaviors: constraint enforcement, auto-generated relations, row state tracking, AcceptChanges/RejectChanges state machines, etc. These can change data in ways the developer does not expect.

POCO DataSet avoids all hidden logic. Nothing happens unless your code explicitly performs it. This makes application behavior predictable—critical for debugging, testing, and maintaining large systems.

6. Performance and Memory Footprint

POCO DataSet avoids reflection-heavy operations, boxing, relation graphs, and legacy XML structures. It stores data in efficient internal collections, which makes it suitable for high volume scenarios or per request serialization.

While System.Data.DataSet carries internal structures even when unused, POCO DataSet stays minimal.

7. Alignment with Modern Architecture Styles

POCO DataSet aligns much better with modern .NET development styles:

System.Data.DataSet is tightly tied to early .NET application models and does not integrate naturally with these modern approaches.

Conclusion

POCO DataSet is not just a replacement for System.Data.DataSet—it is a modern rethinking of what a tabular data model should be in a distributed, UI dynamic, JSON centric world. It preserves the simplicity of working with tables and rows while eliminating the complexity and constraints that no longer serve modern applications.