.NET, OData, REST, Visual Studio, Entity Framework

.NET OData Context Generator


OData v4 is a very common data protocol- given that it's REST and HATEOAS compatible- but lacks the refinement, guidance, and type-checking that many .NET developers are used to. The Visual Studio OData v4 Client Code Generator forms an Entity Framework-like wrapper around this HTTP-only protocol.


Any .NET developer who's been in the framework for more than three years is familiar with Entity Framework, an ORM that has shipped with Visual Studio for a decade now. It's very convenient- it provides type checking and intellisense, atomizes database operations, and lets users explore and take advantage of relationships in the entities generated by the EF code.

Visual Studio 2017 still ships with EF, even morphing it into a smaller more asynchronous compatible package called EF core for the ASP.NET Core framework, and it continues to provide useful functionality. Developing for the internet, however, has started to take a much more open-source, platform-indepent turn. Starting a long time ago with the movement toward Service Oriented Architecture and Microservices, and later towards REST and HATEOAS compatibility, the number of developers and frameworks choosing to support direct database access has dwindled. Startups are priding themselves on being completely open to any framework that wants to work with them, which seems like a lofty goal until you realize that standards and restrictions are what often allow productivity to be established and shortcuts and tools to be used.

Microsoft introduced (and recently updated) and add-in to Visual Studio called the Odata v4 Client Code Generator, a tool that, once installed in Visual Studio, will allow users to generate a set of classes very much like an EF database context. The tool uses text transformation and a URL pointer at your OData v4 metadata location to explore all the relationships between the related entities and produce a POCO object for each table and a parent or child relationship for each foreign key. Most of the EF functions are supported- where clauses, include statements, and of course CRUD operations. Changes are persisted to the OData service via an atomic operation (at least in the context; obviously that must also be supported in the OData service also to be functional) and intellisense allows developers to code as easily and quickly as they would with direct DB access.

ata v4 Client Code Generator