Entity Framework Data Compatibility

PocoDataSet is Entity Framework compatible by design. It does not replace Entity Framework, reimplement Entity Framework internals, or couple to DbContext. Instead, it provides a clean, explicit interoperability layer between Entity Framework POCO entities and dynamic, schema-driven datasets. Entity Framework remains your persistence engine and POCO DataSet becomes a neutral, UI-friendly data surface. Entity Framework does what it does best - persistence, POCO DataSet does what it does best - dynamic data orchestration.

The Integration Boundary

The integration is intentionally limited to three methods for moving data between POCO entities and POCO DataSet rows: CopyFromPoco, CopyToPoco, and ToPoco. For saving changes back through Entity Framework, PocoDataSet provides an explicit bridge layer (PocoDataSet.EfCoreBridge) that applies a POCO DataSet changeset as a PATCH payload.

High-level sequence of steps for enabling dynamic functionality with Entity Framework through PocoDataSet:

• Use Entity Framework DbContext to retrieve data as POCO entities
• Call CopyFromPoco to project entities into POCO DataSet rows
• Send POCO DataSet to UI layer (or merge into an Observable POCO DataSet)
• Users edit data in POCO DataSet (no EF tracking in the UI layer)
• Create a changeset (as POCO DataSet) that contains only captured changes
• Apply the changeset to EF entities using PocoDataSet.EfCoreBridge and call SaveChanges

Key Concept: Changesets Are PATCH Payloads

PocoDataSet changesets are delta changesets:

• Modified rows are floating (sparse): they contain only primary key(s) and the fields that were actually changed.
• Deleted rows are minimal: they contain only primary key(s) (and optionally a concurrency token if you include it).
• Missing field is not the same as null: missing means "not provided"; null means "explicitly set to null".

This aligns naturally with EF Core partial updates: the bridge sets only provided properties and marks only those properties as modified. Unknown fields can be preserved during JSON round-trip for forward compatibility, but they are ignored by the EF bridge when applying to strongly typed entities.

End-to-End Example

1. Read with Entity Framework

using (var db = new AppDbContext())
{
    List<Department> entities = db.Departments.ToList();
}

2. Project Entity Framework Entities into PocoDataSet

IDataSet dataSet = DataSetFactory.CreateDataSet();
IDataTable table = dataSet.AddNewTable("Department");

table.AddColumn("Id", DataTypeNames.INT32, false, true);
table.AddColumn("Name", DataTypeNames.STRING);
table.AddColumn("Description", DataTypeNames.STRING);
table.AddColumn("RowVersion", DataTypeNames.BINARY); // optional concurrency token

foreach (Department entity in entities)
{
    IDataRow row = table.AddNewRow();
    row.CopyFromPoco(entity);
    row.AcceptChanges(); // marks row as Unchanged (baseline)
}

At this point, the dataset is detached from Entity Framework and safe for UI editing.

3. Edit in the dynamic UI

• Dynamic forms generated from metadata
• Search result editors
• Tree views and master / detail layouts
• Offline or staged editing

All edits occur against POCO DataSet, not Entity Framework entities.

4. Create a delta changeset

IDataSet changeset = dataSet.CreateChangeset();

// In the changeset table:
// - Modified rows contain only primary key(s) + changed fields
// - Deleted rows contain only primary key(s) (and optionally RowVersion if you include it)

5. Apply the changeset back to Entity Framework using PocoDataSet.EfCoreBridge

using (var db = new AppDbContext())
{
    IDataTable csTable = changeset.Tables["Department"];

    // ApplyTableAndSave loads tracked entities by primary key, applies only provided fields,
    // marks only those fields as modified, and executes Add / Update / Delete as needed.
    EfChangesetToPocoApplier.ApplyTableAndSave(db, db.Departments, csTable);
}

What POCO DataSet Does NOT Do

POCO DataSet intentionally avoids:

• Entity Framework change tracking replication
• Lazy loading
• Navigation property fixups
• DbContext lifetime management
• ORM-level conflict resolution policies (it leaves this to your domain/application layer)

This keeps the POCO DataSet architecture predictable, testable, and decoupled.

Summary

• POCO DataSet works with Entity Framework Core without coupling
• Changesets are delta (floating) payloads: only what changed is sent back
• EF bridge applies changesets as PATCH updates (only provided fields are updated)
• Ideal for dynamic UI and metadata-driven applications
• No ORM lock-in
• Integration is explicit, predictable, and test-backed

If you are already using Entity Framework for persistence and you need a dynamic UI-friendly data surface, POCO DataSet fits naturally into your architecture.

 

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.