Today I’m pleased to announce a combined effort of myself and Devlin Liles which we are calling The Highway Framework, “The fastest and smoothest way to great architecture”. For this initial release we’ve focused on data access architecture with Entity Framework, a topic we’ve recently written a book about, but you can expect further greatness from us on other topics in the future. As you most likely know, Devlin and I are both consultants with Improving Enterprises and this is framework definitely distills alot of learning from our various clients and from other Improving consultants. We invite you to read on, check out the source code on github, our API Documentation, review the website, and tells us what you think. All that said, let’s tell you about Highway.Data.
This project focuses on bringing our recommendations for data access, specifically the Repository and Specification patterns. For this intial release we’ve focused on delivering these for Entity Framework, but in the future you can look foward implementations for NHibernate and other data access structures. If we’re going to work with Entity Framework in a code first fashion, we will need some POCOs. Our guidance with Highway.Data is not to use the Mapping attributes, which instantly make your POCOs aware of your database, but rather to use a mapping class. We provide an interface you can implement to configure your Entity Framework mappings, it is called IMappingConfiguration. So let’s say we’re working with the following POCO:
1 2 3 4 5 6 7
We can create a very simply mapping class to store that in the database in the People table:
1 2 3 4 5 6 7 8 9
Now all that is left is to register with our container, and we’re off and running. For this demo, we’ll show how to do that with Castle.Windsor:
1 2 3 4 5 6 7 8 9 10 11 12 13 14
We now have a completely wired up Highway.Data implementation, and can resolved IRepository into any of our classes which need to access data. But that’s only the first half of Highway.Data.
In addition to a repository pattern implementation, we also provide an implementation of Specification pattern in Highway.Data. We use the pattern to ensure our queries are all testable, without access to a database, and also to be able to quickly enumerate, and if necessary generate SQL for, all the queries are project uses. There are few things that will make a DBA smile more than to learn that a project using an ORM can quickly produce for him or her a list of all queries used by that application. That said, let me show you how you create a simple query against the LastName property of our Person.
1 2 3 4 5 6 7 8
As you can see, we create a class to represent our query, and provide the query implementation to the ContextQuery property. Once we’ve created this query, using it is as simple as:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Obviously, this could be any class in your application, we depend on an IRepository, and hand the Find method our query, and our query it’s parameter. And that’s it!
We provide three NuGet Packages:
- Highway.Data.EntityFramework is the package most people will use, and contains our full Entity Framework implementation.
- Highway.Data.EntityFramework.Castle contains a Windsor Installer already setup for everything Highway.Data needs other than your Repository, Context and Mappings.
- Highway.Data is our core abstractions, without an ORM dependency.