dotnetrocks 0638 rob eisenberg

architecting the solutions. For me it would have been
a much bigger issue I'd say to have to come to the
phone and rethink everything entirely and think about
how I build things entirely differently.
Richard Campbell: Yeah.
Rob Eisenberg: So what Caliburn.Micro lets
you do is sort of use the same conventions, the same
mental approach to solving problems across the three
platforms even if there are some slight differences
here and there. But mainly the mental overhead is
not there to be switching back and forth between how
you’re architecting things. You can think the same
way, solve problems the same way. You just might
have a different control on the phone or the root might
start with the View, a navigation architecture that's a
little bit different or what-not, but mainly you can think
the same way about solving those problems. For me
that's where the big time savings has come in over
the years. It's taken a long time to sort of understand
and work through these patterns, these concepts, and
see simple and elegant ways to solve them. It's funny
actually because it oftentimes takes a really long time
to come around to the simple solution. I found that
my first way of solving problems has been really
complicated, but over the years I've come around to
very simple solutions for things. So I want to keep
that simple mindset when I'm going across these
platforms and not have to start over from scratch
mentally and go through that whole process again.
That's a great help to me and I've seen a lot of good
response from phone developers using the
framework. They really just, they like the mental
approach and the way of composing apps. They like
that there's a fairly seamless transition from WPF or
Silverlight into the phone for them. There are not any
new concepts they need to learn. They just need to
realize, oh, we don't have a tab control on the phone
but we do have this pivot control, and they're
conceptually the same kind of UI and they can work
with the ViewModel in conceptually the same kind of a
way so they can engineer their ViewModel the same
as they always did but just throw a different type of a
View on top of it. That becomes really powerful.
Carl Franklin: So tell us quickly, because I
know we only have a few minutes left, what the
difference between Caliburn and Caliburn.Micro is.
Rob Eisenberg: Right. So that's kind of a
critical point that may be confusing to people at this
point. The first framework was Caliburn, and, like I
said, it came into existence some time in 2007 and it
has evolved a lot. It was originally designed for WPF
and it was designed for larger applications. It's
extremely modular in the traditional sense that there
are interfaces for all its services. You can customize
and replace everything. It has a lot of adaptors to
other external projects so if you want to use IoC with
Rob Eisenberg MVVMs Us with Caliburn.Micro!
February 17, 2011
it, we have adaptors for every major IoC container.
It's rather large and, though the feature set is very
nice, I found that developers, though they were
enticed by it, were a little bit afraid to use it because
of its complexity and because they had a little bit of
dependency on some legacy. In fact they called
Legacy WPF. In other words, things that they fixed
later on or improved that I wasn't able to take
advantage of at that time. So I wanted to expose
developers to the concept of conventions and actions
and all these neat things we were doing. So at MIX
last year I had the chance to do a session called Build
Your Own MVVM Framework in which I basically
wrote a little itty-bitty framework, about 500 lines of
code, that showed how you could build a lot of these
features very simply and how much productivity you
can get out of it. I got so much positive response
from that, from individuals as well as companies that
were just highly interested in seeing that fleshed out a
little bit more, that I decided to see if I could roughly
expand it but only so much as to cover the main-use
cases that Caliburn had covered, like 80% to 90% of
the main-use cases, without worrying too much about
edge cases and to keep it as small and tight and
compact as possible. So that's where the
Caliburn.Micro came.
Carl Franklin: Okay.
Rob Eisenberg: It's about 10% of the code size
of Caliburn but it literally has 80% to 90% of the
features because it focused so much on the main
cases. So it's a lot simpler, a lot easier to understand.
It's a little bit more up to date in terms of some of the
new features in the framework and how it leverages
them.
Carl Franklin: We've added a link also to the
Caliburn vs. Caliburn.Micro page on CodePlex and a
couple of things that you've mentioned here. Caliburn
supports AOP, Aspect-Oriented Programming.
Caliburn has a validation abstraction, a module
framework, a testability framework, a ViewModel
factory. So there are differences. But you also say "I
prefer to use Caliburn.Micro over Caliburn." That's
what you say also.
Richard Campbell: Well, it feels like it's a next
version.
Rob Eisenberg: It is a next in a sense a new
version. It's almost like if I could do this over again. . .
Richard Campbell: Yeah. I've had that experience
where after finishing a really complex project I sat
down and noodled it down again, like how could you
take it on differently and you end up writing 90% of
the functionality in 20% of the code.
Transcription by PWOP Productions, http://www.pwop.com Page 12 of 13