GDG.SharePoint ADOProvider Technical overview
Enterprise SharePoint data access

Treat SharePoint data like application data.

GDG.SharePoint.ADOProvider brings an ADO.NET-oriented programming model to SharePoint, enabling .NET applications to work with lists and document libraries through a clean, REST-only data access layer.

Explore the architecture View capabilities
Runtime REST only
Targets SharePoint Online + SE
Developer model ADO.NET + SQL-like
GDG.SharePoint.ADOProvider REST
Application
.NET
Business Application Desktop · Web · Services
ADO.NET-style access
GDG
ADOProvider Connection · Commands · Mapping
SharePoint REST API
SP
SharePoint Lists · Libraries · Attachments
No CSOM dependency
Schema-aware
Enterprise ready
API strategy REST-first by design
Data model Lists as structured data
Built for .NET teams Reduce SharePoint-specific plumbing in business applications.
ADO.NET provider model SQL-like language REST architecture Schema caching
The platform

A pragmatic data-access layer for SharePoint.

SharePoint is powerful, but application code often becomes tightly coupled to platform-specific APIs. GDG.SharePoint.ADOProvider introduces a familiar data-access abstraction so .NET solutions can keep infrastructure concerns behind a consistent provider layer.

01

REST-only runtime

Designed around SharePoint REST endpoints, without a CSOM runtime dependency in the provider architecture.

Modern integration boundary
02

ADO.NET-oriented access

Bring established .NET data-access patterns closer to SharePoint lists and libraries, reducing the conceptual gap with relational application code.

Familiar developer model
03

Enterprise scope

Target solutions that need governed, reusable access to SharePoint Online and SharePoint Subscription Edition data.

Online + on-premises
Architecture

One provider boundary.
Multiple application patterns.

Keep SharePoint transport, schema discovery, query execution and object mapping behind a dedicated provider instead of scattering REST-specific code across the application.

Consumers
DesktopWinForms / Wisej.NET
WebASP.NET / Blazor
ServicesWorkers / APIs
Data LayersDapper / ORM adapters
CORE PROVIDER

GDG.SharePoint.ADOProvider

Connection management Command execution Schema metadata Type conversion CRUD orchestration Attachment handling
HTTPS / REST
SharePoint Online Microsoft 365 environments
SharePoint Subscription Edition Enterprise on-premises environments
i

Design principle: SharePoint remains SharePoint. The provider does not pretend that lists are a relational database; it gives application developers a disciplined data-access abstraction while preserving SharePoint semantics underneath.

Core capabilities

Designed around real application workloads.

A provider architecture focused on the operations enterprise .NET applications need most when SharePoint becomes part of their operational data landscape.

Lists and document libraries

Access structured SharePoint content through a unified provider model suitable for business applications, integration services and reusable repositories.

CRUD operations

Create, read, update and delete content through a consistent application-facing layer.

Schema awareness

Discover SharePoint field metadata and reuse cached schema information to limit avoidable calls.

Files and attachments

Support application workflows that include SharePoint documents and list-item attachments.

Type mapping

Translate SharePoint field values into application-friendly .NET data representations.

Performance-conscious access

Centralize schema reuse and transport concerns in the provider layer, creating a better foundation for predictable application behavior and future optimization.

SQL-like language

Query SharePoint with a language .NET developers already understand.

GDG.SharePoint.ADOProvider includes a SQL tokenizer, parser and execution pipeline. SQL statements are translated into SharePoint-aware query and mutation operations, while the application remains on the standard ADO.NET programming model.

CustomerQuery.sql
SELECT 
SELECT TOP 100
    ID,
    Title,
    Status
FROM Tasks
WHERE Status = 'Open'
ORDER BY ID DESC;
01
SQL enters the provider pipeline

The provider tokenizes and parses the statement into its internal execution plan.

02
SharePoint-aware pushdown

SELECT filtering and projection are pushed server-side through the provider's SharePoint query pipeline whenever possible.

03
Standard ADO.NET consumption

Results are exposed through DbCommand and DbDataReader semantics instead of SharePoint-specific client APIs.

INSERT List item 
INSERT INTO Customers
    (Title, Email)
VALUES
    ('Mario Rossi',
     'mario@example.com');
UPDATE Business data 
UPDATE Customers
SET Status = 'Inactive'
WHERE ID = 42;
DELETE List item 
DELETE FROM Customers
WHERE ID = 42;
DOCUMENT UPLOAD Library 
INSERT INTO Documents
    (FileName, FileContent, Title)
VALUES
    ('Contract.pdf',
     @Content,
     'Contract 2026');
ADO.NET usage

Use standard provider abstractions.

The provider exposes DbConnection, DbCommand, DbDataReader, DbParameter and DbProviderFactory-compatible types, allowing SharePoint access to fit established .NET data-access architectures.

DbConnection DbCommand DbDataReader DbParameter DbProviderFactory
Program.cs
C# 
using DbConnection connection =
    factory.CreateConnection();

connection.ConnectionString = connectionString;
connection.Open();

using DbCommand command =
    connection.CreateCommand();

command.CommandText =
    "SELECT ID, Title FROM Customers " +
    "WHERE ID = @Id";

DbParameter p = command.CreateParameter();
p.ParameterName = "@Id";
p.DbType = DbType.Int32;
p.Value = 42;
command.Parameters.Add(p);

using DbDataReader reader =
    command.ExecuteReader();
SQL syntax is interpreted by GDG.SharePoint.ADOProvider and translated to SharePoint operations. SharePoint remains the underlying data platform; the provider preserves SharePoint-specific semantics rather than emulating a relational database server.
Integration strategy

Use SharePoint without making your entire application SharePoint-aware.

Keep domain logic, UI layers and application services focused on business behavior. Let the provider own the SharePoint-specific transport and metadata concerns.

✓

Repository-friendly
Fits cleanly behind repository and service-layer abstractions.

✓

Dapper / ORM integration path
Suitable as a foundation for adapters that bring SharePoint closer to established data-access tooling.

✓

UI-neutral
Consumable from desktop, web and service workloads without tying the provider to a specific presentation stack.

APPLICATION Business Logic & Domain Services
↓
DATA ACCESS Repositories · Dapper adapters · Custom DAL
↓
PROVIDER GDG.SharePoint.ADOProvider
↓
PLATFORM SharePoint REST API
Why it matters

Lower coupling. Clearer architecture. Faster delivery.

01

Reduce platform-specific code

Move repetitive REST plumbing out of business features and into one reusable data-access boundary.

02

Standardize development patterns

Give .NET teams a more familiar mental model for SharePoint-backed application data.

03

Improve maintainability

Concentrate authentication, schema, transport and mapping concerns where they can evolve independently.

04

Bridge legacy and modern workloads

Support enterprise applications that need SharePoint data without forcing a complete architectural rewrite.

Enterprise positioning

For teams that need SharePoint integration to behave like infrastructure.

System integrators Enterprise .NET teams Line-of-business applications Modernization projects
Controlled technical access & NDA requirement

Source repository access is not public. Qualified partners, authorized evaluators and approved integration teams must request access by email at info@gabrieledelgiovine.it. Access is granted only after the required project-specific Non-Disclosure Agreements have been reviewed and signed.

GDG.SharePoint.ADOProvider

Build cleaner .NET applications on top of SharePoint.

Evaluate the provider for enterprise application development, modernization, integration platforms and reusable SharePoint data-access architectures.

Review platform Request repository access — NDA required
Private source repository — NDA protected Access is reserved for qualified partners and authorized evaluators. Requests must be sent to info@gabrieledelgiovine.it and are subject to specific Non-Disclosure Agreements before repository access is granted.