dotnetrocks 0638 rob eisenberg

Recommendations

Info

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
Carl Franklin: Am I right in assuming that a lot of this functionality has been replaced with good conventions? Rob Eisenberg: A lot of it has although what I've been doing with Caliburn 2.0 is trying to maintain API compatibility between the two in the areas that a developer would touch the framework the most. So, for example, all the conductors are code-identical in their implementation. But the conventions, while they are the same between the two frameworks, they're implemented very differently between the two. Carl Franklin: Yeah. Rob Eisenberg: So there are things like that. Like you said, I have a validation infrastructure abstraction in Caliburn. Well, that abstraction is not present in Micro. I think when I looked back at Caliburn, there was some unnecessary abstraction there. There were things like that that because there was so much variance in the way that the developers wanted to do particular things, I created these elaborate abstractions. On Caliburn.Micro I just said, well, I'm just not going to go there. Carl Franklin: Yeah. Rob Eisenberg: I'll just make sure that they have some point where they could plug in feature X if they do wanted to deal with it. So that eliminates a lot of code and it turns out that most of those things, like validation, it's pretty simple to, you know, if they're going to use that out-of-the-box attribute validation, to just write a little class and plug it into the right place than to deal with like having to implement my abstraction and then plug in all that. So it was some rethinking around those things. I really focused on the main-use cases and making it small. Carl Franklin: Great. Rob Eisenberg: It's what I use now. I use Caliburn.Micro on all my new projects and I encourage people to do that. There have even been some people that have missed some features in it that they like in Caliburn, but Micro is extensible enough in the right places where they actually came up with ways to implement those features. Like some of the AOP stuff that we did with Caliburn, you can actually implement very simply and plug in to the right place in Micro if you want that feature, but we don't provide it out of the box. Carl Franklin: Well, Rob, it's been eyeopening, and thank you for being so succinct and such a great speaker. It's a great framework and it's obvious to me the benefit to using it. Rob Eisenberg MVVMs Us with Caliburn.Micro! February 17, 2011 Rob Eisenberg: Well, thank you for having me, and hopefully listeners will have some new ideas, new ways of thinking about how they might get rid of that boilerplate code they're working on. And, even if they don’t want to use Caliburn.Micro, it's a fun thing to sort of take a look at and just pick some ideas about different ways to do things. Carl Franklin: Awesome. Well, and we've put a whole bunch of links and your bio also, your Twitter handle and all that, on the .NET Rocks! page. So head on over there for that information. Thank you very much again, and thank you for listening. We'll see you next time on .NET Rocks! [Music] Carl Franklin: .NET Rocks! is recorded and produced by PWOP Productions, providing professional audio, audio mastering, video, post production, and podcasting services, online at www.pwop.com. .NET Rocks! is a production of Franklins.Net, training developers to work smarter and offering custom onsite classes in Microsoft development technology with expert developers, online at www.franklins.net. For more .NET Rocks! episodes and to subscribe to the podcast feeds, go to our website at www.dotnetrocks.com. Transcription by PWOP Productions, http://www.pwop.com Page 13 of 13
Page 1 and 2: HTTP://www.dotnetrocks.com Carl Fra
Page 3 and 4: Pandhi, our resident graphics and A
Page 5 and 6: Rob Eisenberg: The blue screen. Tha
Page 7 and 8: ind them together and so on and so
Page 9 and 10: Rob Eisenberg: It's got a simple ba
Page 11: Rob Eisenberg: But each one them wo

dotnetrocks 0638 rob eisenberg

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?