Saturday 29 March 2014

F# Type Providers

Solving F# problems at a Skills Matter session earlier this week allowed me to fully appreciate the power of the Type Provider. The task can be found here for those interested: https://github.com/tpetricek/Dojo-Type-Provider-Treasure-Hunt

The aim of this post is not to provide the solution to the problem but to underline useful of the type provider - which was the ultimate goal behind the exercise. Type Providers succeed at bridging the gap between code and data. Type providers makes data easy to navigate by extracting the schema and publishing it through intellisense.

This is a gift for developers who are used to working with static types. Type Providers have been written for all the most popular data sources, so you can perform tasks against almost anything as though it had already been translated into domain objects. This is often the goal of an ORM, to abstract away the plumbing of persistence interaction. However, Type Providers are more data-driven rather than being a 'code first' affair. You specify the source of the data and the Type Provider will do the heavy lifting of examining the schema, taking the naming conventions and sample data and presenting the developer with a suitable API to explore.

If you were to try to do this with an ORM you would need to create the DTO classes yourself and plug them into the Data Context (or equivalent). Type Providers are productivity boosting in this sense as they require very little bootstrapping.

The power of intellisense:




Type Providers have done what WCF Web Services did - making strongly typed data access possible over a network - but has liberated the publisher of that data to do so in whatever format they choose. Previously, if you wanted your data to be discoverable to the developer in the IDE you would have needed to create a Web Service wrapper around your data and model all the types yourself. Now you can just provide direct access to the data source and let Type Providers do the rest!

I'm yet to make use of FunScript but this looks like a great implementation of a Type Provider - applying the same principles to the html DOM API. Meaning you can create strongly typed web pages! It even includes common js libraries so you can create rich SPAs and interact with your domain with the same workflow and familiarity across both contexts.

5 comments:

  1. What is perfect about JS for JavaScript software engineers, it is viable with a large number of present day programs and, hence, can be seen from any gadget or operating system. Each passage level JavaScript engineer remote realizes that JS can be seen with Adobe administrations, server-side conditions, data sets, SVG pictures, and so forth. JavaScript software engineers including a lesser JavaScript designer remote use JavaScript language for a wide extent of utilizations.

    Here you can find considerably more ideas on the ventures that can be performed with JavaScript capabilities. How about we consider the advantages and disadvantages of JavaScript application advancement each lesser JavaScript designer remote knows without a doubt>> best sites to hire javascript developers

    ReplyDelete