One Table, Many Contracts

One of the important features of POCO DataSet is the ability to expose the same physical table row through different interface contracts. The table name remains the human-readable marker that tells the system what kind of data the table carries, while interfaces describe how a particular consumer wants to read or update that data.

This creates a useful separation between data transportation and data interpretation. A table can carry a rich, aggregated result, while different layers, handlers, screens, validators, or services can consume only the part of the row that belongs to their contract.

The Problem: DTO Explosion

Enterprise applications often need several representations of the same business information. A search screen may need display fields, a validator may need rule-related fields, a persistence operation may need identifiers, and a transition handler may need process metadata.

With a traditional DTO approach, this frequently produces many similar classes and repeated mapping code:

Database result -> Search DTO
Database result -> Validation DTO
Database result -> Persistence DTO
Database result -> Transition DTO

Each additional DTO introduces copying, mapping, and synchronization risk. When the data shape changes, several models and mappings may need to be updated even though the underlying data is still the same.

Aggregated Tables

A POCO DataTable does not have to correspond to one database table. It may represent a logical result assembled from several database tables, stored procedures, views, joins, or service responses.

For example, an EmployeeSearchResult table may contain columns that came from Employee, Department, Manager, and Salary-related data:

EmployeeSearchResult
    EmployeeId
    EmployeeName
    DepartmentId
    DepartmentName
    ManagerName
    SalaryGrade
    IsActive

The table name explains the business purpose of the result. The columns carry the available data. Interfaces then allow different consumers to view that same row through narrower, purpose-specific contracts.

Interface Projections

An interface projection is a live contract view over the same underlying data row. The interface does not own the data and does not create a copy. It simply exposes selected columns as strongly typed properties.

public interface IEmployeeSearchView
{
    int EmployeeId { get; set; }
    string EmployeeName { get; set; }
    string DepartmentName { get; set; }
}

public interface IEmployeeValidationView
{
    int EmployeeId { get; set; }
    int DepartmentId { get; set; }
    bool IsActive { get; set; }
}

public interface IEmployeeManagementView
{
    int EmployeeId { get; set; }
    string EmployeeName { get; set; }
    string ManagerName { get; set; }
}

The same row can be projected into any of these interfaces when the requested properties can be matched to row columns:

IDataRow employeeRow = employeeSearchResult.Rows[0];

IEmployeeSearchView searchView = employeeRow.AsInterface<IEmployeeSearchView>();
IEmployeeValidationView validationView = employeeRow.AsInterface<IEmployeeValidationView>();
IEmployeeManagementView managementView = employeeRow.AsInterface<IEmployeeManagementView>();

All three variables refer to views over the same row. A consumer receives the shape it needs without forcing the table to become a single rigid object model.

Disaggregation by Contract

This pattern can be understood as disaggregation by contract. The table may be physically aggregated, because it contains data collected from multiple sources. The consuming code can still work with logically disaggregated contracts that expose only the fields needed by that part of the system.

The result is a simple but powerful rule:

Store and transport the data once. Interpret it through as many contracts as the application needs.

Why This Matters

• The same data row can serve multiple consumers without creating duplicate DTOs.
• Aggregated service or database results can remain intact while still being consumed through narrow contracts.
• Interface contracts make the intended use of data explicit.
• There is no need to remap values from one object model into another when a different consumer needs a different view.
• Data changes remain centralized in the underlying row instead of being spread across several copied objects.

Summary

Interface projections turn POCO DataSet from a simple tabular container into a contract-driven data access model. A table can carry aggregated business data, and the same row can be viewed through multiple interfaces without copying, remapping, or creating DTO families for every consumer.

One table. Many contracts. Zero remapping.

 

Table of Content POCO DataSet Concepts Previous: Table and Row Organization Next: Schema-Driven Relations

 

---

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.