Last week I gave an internal presentation to my fellow consultants at CGI on the principals of data modelling/data architecture, modelling within Visual Studio 2013 and a history of the (ADO.NET) Entity Framework.
I’ve attached the slide deck to this article, and also in my presentations page.
Data Modelling – Concepts
Once we get past the initial introductions, I dove into some of the fundamental principles of data access design. These are the key design considerations which every mature solution should take into consideration – particularly when building a design which marries to the ACID principles.
This part of the presentation wasn’t directly related to either data modelling in Visual Studio or implementing the Entity Framework ORM, but I don’t think it is a bad idea to restate some core data access design goals where possible.
Once we were past the concepts, we went straight into…
Visual Studio 2013 Database Projects
To be honest with you, I forced myself to use Visual Studio’s out-of-the-box database project as a design tool instead of jumping into SQL Management Studio as I normally would. Partly, this was to give the tools some fair use – the designer support is still a bit sluggish – but there’s still some niceties to be had here.
The latest incarnation has some decent and attractive features, the SQL Compare functionality is simply superb for harmonizing T-SQL based on instances or other code repositories, and the T-SQL import wizard helps with getting projects up and running quickly.
Possibly the best feature is the publishing wizard, which you can use to easily deploy to SQL Azure or to instances; or to run as part of an automated build.
The Entity Framework
Besides showing how the entity model is generated from the database schema, I wanted to impress upon the audience the costs vs. benefits of adopting an ORM solution – particularly focused on the quick wins against the limitations and potential performance problems.
Ultimately this lead into a review of a generic interface pattern which I’ve been working on for the past few weeks, and some of the power of consolidating common data access methods (e.g. Create, Read, Update and Delete) into a common implementation using generics.
At the end, I was planning to surprise the audience by “live switching” from accessing a local SQL instance to querying data from SQL Azure by simply changing a connection string, but due to having to move rooms at the last minute, the 4G connection I was using hadn’t been authorised on the SQL Azure Database, so the surprise failed.
The awesome takeaway (blown surprise aside) was that using the Entity Framework, there was no need to do any recompilation – the model worked seamlessly with local and Azure-based data stores. I guess I’ll have to save that surprise for another audience at another time.
To be honest, I should have split this into two presentations. There’s so much to discuss when it comes to decent data design principles, so I could have talked about those and data modelling in a single session. The Entity Framework represents a large body of work in its own right, I could speak for hours about how it can be adapted and extended.
We didn’t even scratch the surface.. This may lead to a follow-up presentation potentially. Here’s the slide deck from the day.