As the saying goes, there is no problem which can’t be solved by adding another layer of abstraction. If you’ve ever sweated making a choice between two products—loggers like Loupe or Splunk, SimpleDB or DynamoDB, for instance—and one of the main drivers of making the “right” choice was the pain of switching, maybe you should have spent some time looking into a layer of abstraction. Slow starts to projects are often due to paralysis-via-analysis.
A framework is just such a layer of abstraction. Frameworks are well designed set of code which allow you implement or switch relatively easily between different different choices of the same thing. Concerns about the “right” choice can be answered with “don’t sweat it, we’ll implement a factory so we can use any log provider, or even different log providers based on severity”, or “no sweat, we’ll encapsulate all our data calls in a data provider, so we just need to replace the one class if we switch databases”. With the right layers in place, you’re liberated to try a few different options, easily implement the best tool for the job, and not worry too much about future changes.
Frameworks might be the high level of abstraction we need, but how does this usefulness get here?
Where Do Frameworks Come From?
We developers all start somewhere, and aside from prodigies, we all start at level of “procedural code”. We write big long procedures that get the job done. Very quickly we learn how to break chunks of code into methods, and then classes. This is the basis of OOP and confers all the benefits OOP is known for.
Library abstraction comes from working with a number of similar applications, seeing commonalities between these applications, and creating a set of classes of only the commonly used code. This set of classes is a library, and managing libraries in several applications creates problems while solving others. The hassle of managing libraries is why NuGet, npm, pip and other “package managers” were created. Libraries are usually tied closely to the set of applications they were developed for.
Nearing the top level of developer thought development is framework abstraction. Frameworks employ design patterns (such as provider, factory and abstract factory) which enable components to be very easily swapped around. Frameworks aren’t supercharged libraries, they’re really meant to be super-generic libraries, encapsulating very common activities (such as logging) into a generic form. Good applications will use one or more generic frameworks in addition to one or more libraries specific to that application set.
I’ve illustrated this all with a handy-dandy PowerPoint Smart Art:
Note: there is no scientific basis for the above diagram, I totally made it up. But I believe it to be as accurate as anything else I make up. If you don’t know what “gunga galunga” means, see https://www.youtube.com/watch?v=TkLH56VlKT0.
Why Use a Framework?
Gaining the experience to develop a framework can take a lot of time, in addition to the time it takes to actually develop the framework. Starting with an existing framework (especially an open source one) allows you to leverage common experiences (i.e., someone else already crossed the bride you’re about to) and speeds your time to SOLID code. Your application will implement best practices from the start, leading to faster maturity of your application. The flexibility a framework provides sets you up for success by making change easy.
Using an existing framework means you’re participating an ecosystem which welcomes contributions, and becoming a contributor moves you up a level or two on the pyramid above, and helps ensure the longevity of the project.
Why Rock Framework?
The Rock Framework is literally “developed by dozens, used by hundreds”. We use Rock Framework internally in hundreds of applications, and have open-sourced the parts we can share. We have a saying at QuickenLoans—“take the roast out of the oven”. It means don’t spend too much time thinking about a problem, it’s better to try some things out. The Rock Framework gives us all the basic plumbing to easily try things out, plus some nice syntactic sugar we like to use in our applications.
Rock Framework is available as several NuGet packages, and the source code is hosted on GitHub, both of which you should access via http://rockframework.org/. Here, I’ll describe the packages available now. Other features and packages will be added in the future so be sure to refer to http://rockframework.org/ for the most up-to-date information.
This is the base package for the Rock Framework, and is a dependency for the other RF modules. It contains XSerializer (a non-contract XML serializer), a wrapper for Newtonsoft’s JSON.NET, a dependency injection container, a wrapper for hashing, a number of extension methods, and more.
This is probably the module with the most immediate use. All logging methods are encapsulated, and there is a provider model with several interfaces for different types of log messages. You’re encouraged to extend both your internal implementation as well as our repo with providers for popular logging platforms.
If you’re planning to implement message queuing between applications (using MSMQ, RabbitMQ or named pipes, for example), this library contains message primatives as well as routers, parsers and locator classes to get a full featured messaging system up and running in very little time. If you use the interfaces you’ll be able to easily swap providers if you’re taking some for a test drive.
Last, but not least, here is a DI framework which forms the basis for swappable parts in the Rock Framework libraries. Applications have entry points (like Main()) where dependencies can be wired up when the application starts. Libraries, on the other hand, don’t have entry points, meaning libraries need to be created and have values set in a constructor or other composition root by the application which uses the library.
Rock.StaticDependencyInjection enables libraries to automatically wire up their own dependencies, even with the ability to automatically find the proper implementation of an interface and inject that.
Get Involved with Rock Framework
This post has just been an overview of the Rock Framework. There are more to come, both from myself and other members of the community. Follow https://twitter.com/rockframework for announcements. Even, better, get involved! As an open source project, Rock Framework has many needs:
- Contribute providers for your favorite logging tool
- Create an example
- Implement the framework in one of your projects
- Write or update documentation
In today’s market, there is no better way to level up your career than to contribute to open source projects like this. We’re looking forward to working with all of you!