Unity Workshop
Awww jyea! I'm officially slated a spot in the Unity Workshop announced earlier this week. This will be a tremendous opportunity to dive further into my latest conceptual toy: Dependency Injection. I learned about DI when I started diving into the bowels of EntLib 3.1. All paths pointed to this ObjectBuilder.dll. I had to find out more about it.
There are a lot of DI frameworks out there, but strangely enough none by the big MS. I found this sort of strange. The more I became enamored by this new toy (and the resulting power it brings), the more I scratched my head wondering why on earth there wasn't something like this for EntLib or from MS.
So, for my first run at building an application block, I set out to build an ObjectBuilder Application Block. :) I actually have it completed, with full-on designer support, and was going to release it on CodePlex until I found out about Unity.
Mr. Hollander brings up a pretty great question about the time being spent on Unity. Although I share his concern with the energy being spent on refactoring (it's the ultimate balance every great developer must learn), I would like to interject a point of my own.
I have great respect for EntLib. In fact, I'd have to rank it in the top 3 public codebases I've encountered in my little journey of software development. It tackles a lot of problems and I believe the design is very well-rounded. I've learned an incredible amount of knowledge from studying this codebase, probably just as much or more so than the .NET Framework (I'm a Reflector Whore). EntLib is a great reference tool, in addition to being a great productivity tool. As such, I believe the refactoring is very much worth the time. A codebase like this should offer Best Practices (since it is Patterns and Practices!) on how to develop a enterprise-level and scalable solution. It's imperative that it shows developers the Right Way of doing things. If that means finding obvious flaws and spending a couple weeks fixing them, then do it.
I guess the point I'm trying to share is that there is a lot more value to this framework than just its functionality. We should keep that in mind when time spent into refactoring comes into play.
And yes, I for one am a little taken aback by all the assemblers and configuration. That didn't stop me from mimmicking them in my own solution, however. (I had to try it out first to get the eyebrow-raise). :)
Finally, I would like to encourage the EntLib team to PLEASE PLEASE PLEASE put more effort into the Configuration Designer in EntLib. In fact, ScottGu or someone over in the .NET team should really take this thing and run with it. We as developers should never ever EVER have to touch a line of XML to configure our applications. That's tantamount to pulling open a command prompt these days. It's 2008, you know. :) I would really like to see the Configuration Editor turn into a full-scale application, complete with Redo/Undo and the like. The interface needs to go through a information architect and user experience expert and make this a Real Deal application. Configuration is King with application development and honestly, I didn't get the big "aha" moment with EntLib until I saw how you could create design components for your application block and run them through the Configuration Design console.
Ok, off my soapbox for now...