David Fowler mentioned the new Microsoft.Data collection of classes as a simple wrapper around ADO.NET to simplify access to a database for querying and CRUD services. Those of us who have been around the block will compare this to the old SqlHelper and Data Access Application Block in Enterprise Library. The wrappers not only reduce the amount of code you write, but also typically embody proven practices around ADO.NET that are often difficult to remember and implement in your own code.
For most .NET Developers, working with ADO.NET and any wrappers is old school. In general, ADO.NET is abstracted by using an O/R Mapper, like LINQ-To-SQL, Entity Framework, NHibernate, LLBLGen Pro, LightSpeed, etc, allowing one to think more about classes and their relationships and letting the O/R Mapper deal with the relational model. It used to be that O/R Mappers were just about abstracting the database, but now they have gotten very sophisticated with change tracking, first and second-level caching, and all kinds of other higher-level services that can benefit your application.
Although I love O/R Mappers and what they provide to my applications and development process, they are overkill for applications that are but a thin, almost transparent, layer on top of a database. Forms-over-data websites and applications just don't need a sophisticated layer of O/R Mapping services and tooling to support it. These applications just pipe data from the database to the web pages and quite frankly don't need anything more than a DataReader, and this is where Microsoft.Data comes in.
Microsoft.Data is for use with WebMatrix and the ASP.NET Web Pages Framework for developing PHP-like applications where data access is primarily all the code you write. The databases tend to be simple, flat, and written to fulfill the needs of the applications, so the data access solution should be just as simple as well. Microsoft.Data has a very simple style for writing parameterized queries ( SQL Injection Safe ) that can be done using NotePad, WebMatrix, or any other simple text editor:
var blog = Database.OpenFile("Blog.sdf");
var post = blog.QuerySingle("SELECT Id, Title, Description FROM Posts WHERE Id=@0", postId);
The complexities of connection management, proper parameterization of queries, when and where to dispose of objects, and other best practices are maintained while allowing the developer to focus on the needs of the application and provide business value at a proper layer of abstraction for this database-driven website. The development environment is also of an appropriate level for these applications that don't need more than a text editor to develop a website.
Now I am just waiting for JetBrains to come out with their new WebStorm IDE to support the ASP.NET Web Pages Framework. You know it's coming :)
David Hayden
Related Posts