It’s really easy to be persuaded by a large framework that does everything. Who would want to tie your shoelaces together by choosing a framework, say an ORM, that does not have support for … say enums? (Sorry, EF I couldn’t resist picking on you.) Who can say no to log4net. After all, it’s comprehensive. It can log messages to files, rolling files, databases, event logs, toilet paper and the Times Square Billboard at rush hour?
NHibernate can do ANYTHING you’d want from an ORM. Now that the current EF CTP supports enums, it’s getting there too. But all the extra functionality comes at a price that you’ll have to pay eventually: Added complexity. Listening to “The Rise of the Micro-ORM with Sam Saffron and Rob Conery” on Hanselminutes, I was inspired by their thougths about going back to basics. Both their ORMs support only basic ORM stuff, but the complexity is way down –- and performance is so much better! Rob made me realize that SQL might just be the ideal DSL for writing queries. I had some of the same ideas when back in 2006, I wrote a simple closed-source ORM called Matterhorn. It was a response to the unnecessary complexity that NHibernate 0.3 introduced in my apps. Back then, when I tried to explain the pain points I had with NH, the reaction I was most often met with was “That’s odd. I haven’t had any problemt with it.”
So Micro-orms to me is great news. I like Dapper, Massive and PetaPoco. Orms are just the beginning. In fact, I think we should expand the notion to “Micro frameworks” to cover all kinds of frameworks from databases to service busses, from IoC containers to rest apis.
The term “Micro framework” might sound a little too much like the Microsoft .NET Micro Framework. So let’s instead go for something even smaller … what about PicoFX?
A dogma needs strict rules. So here are the rules that a framework or api must respect to be a PicoFX:
- Max 1000 Lines of code (excluding Unit tests)
- Only one code file that the user can include in any project
- No dependencies except the .NET BCL
- Must have open source license
- Fully unit tested
I challence you to take a look the framework that you wrote. Rip it apart like Rob Eisenberg did with Caliburn. Take the crucial bits and leave the rest out. Boil it down to under 1000 lines. Is it possible? Then you’ve managed to distill the essense of the framework and leave the fat to the dogs. And chances are performance is improving too.
That should be simple enough, right? Kind of. Once the first version is out and the users start requesting additional features and you have all sorts of great ideas as well, trouble will start brewing. Can you add features and stay below 1000 lines? It’s tempting to add the killer feature thinking that 1156 lines won’t hurt. It’s only a bit more than 1000…
Every feature represents an additional tax, that your users will pay. What if you start taking out one feature every time you add one, respecting the 1000 lines limit? You won’t be 100% backwards compatible. That may hurt some. On the other hand, you’ll be keeping your promise of a simple framework that stays simple.
I’d better chip in and start taking my own medicine. I hereby submit PicoIoC, a 280 line fully functional IoC container. It’s heavily inspired by Autofac and supports registration by type, by lambda or by instance. Automatic lifetime handling means PicoIoC will deal with calling Dispose() if your class implmenets IDisposable. It support abstract factories and Lazy<T>. Yak yak yak. Check it out yourself. I promise you it will stay
I can’t wait to see the PicoFX versions of your framework.
No comments:
Post a Comment