dotnetrocks 0638 rob eisenberg

Recommendations

Info

advanced features on top of method invocation because we let the framework sort of do it for us. I could say without that you’ve either got to go to the code-behind or you've got to do something like people who use a pattern called a Relay Command or Delegating Command where they create a kind of wrapper command object that wraps the method and then proxies it through to the view so that they can actually data-bind it. Basically, it just results in some kind of silly boilerplate code that you just have to mindlessly type in order to connect these pieces together. So we just say, let’s let the framework do that for you, and on top of that because the framework is doing this, we can add even more advanced functionality on top of that. That's one of those smaller level patterns that we sort of implement behind the scenes so the developers don't even need to think about that. Carl Franklin: So one of the conventions that you prefer, Caliburn.Micro prefers, is ViewModel-first development. Tell us about that. Rob Eisenberg: So there's typically two different ways to approach problems when you're trying to work out a solution in your user interface, and it really has to do with the way your approach the pattern mentally and a little bit of the way the framework sort of create features and puts them together. So there's View-first and ViewModel-first. Carl Franklin: Okay. Rob Eisenberg: And with View-first you would start by literally creating your View and then creating your ViewModel, and the framework would do things in that order. In that type of a scenario, the View is really driving things just a little bit more in terms of the interactions, in terms of activating and deactivating different parts of the UI, that you want a lot of that to be in the ViewModel but by the nature of sort of that workflow and the way things are instantiated and put together, the View ends up driving a little bit more. In ViewModel-first, you have the ViewModel created first and then based on that you associate a View with it and it puts the ViewModel in a position to even a greater degree, sort of drive how the Views are composed and how they function and so on and so forth. Carl Franklin: But if you think about it, Viewfirst is, well, it's certainly how I've done most of my development starting back in the days of Visual Basic when you had a great designer that, you know, you sit down with a customer essentially with VB and say, "Okay, so what kinds of things do you want this to do?" Based on that, you sort of come up with the UI first. It seems a more natural way to develop for me because you're really talking about the user's requirements. Rob Eisenberg MVVMs Us with Caliburn.Micro! February 17, 2011 Rob Eisenberg: Absolutely. And practically, when you're actually developing, you would probably have those things happening at the same time. Carl Franklin: Sure. Rob Eisenberg: The important part is that the framework itself, when it goes at runtime and actually puts these things together, it starts with the ViewModel and locates the View and composes them, does some other fancy stuff, and as a result some of the way composition occurs within your user interface is more controlled at runtime by the ViewModel and that can actually make certain user interface scenarios a little bit easier to engineer. So it can be a little bit of perspective from the developer's point of view when they're thinking about solving the problem, but practically when you are actually building your UI you may actually build out the View-first and design with your customer. But at runtime you want the ViewModel to actually drive everything as opposed to the View sort of partially driving it with the ViewModel doing some other part. Carl Franklin: Okay. Rob Eisenberg: So it really has to do with what happens at runtime and how the developer thinks about those interactions between the two. Carl Franklin: This portion of .NET Rocks! is brought to you by our friends at Telerik. So you know all about the power of ASP.NET MVC, but you might be in need of some good tools to enhance your productivity. Well, our friends at Telerik just shipped the latest release of the Telerik extensions for ASP.NET MVC, 18 jQuery-based native MVC extensions. Now you can enhance productivity by remaining in control of your Views without having to write all HTML, CSS, and JavaScript by hand. Did I mention that the Telerik MVC extensions are also free and open source? Plus, now you can check all MVC online demos in both ASPX and Razor Views since the extensions offers full support for ASP.NET MVC 3.0 and the Razor View Engine. Download your free copy today at www.telerik.com/freemvc, and don't forget to thank them for supporting .NET Rocks! So let's talk about the View resolution which, as you say in the docs, is the first convention you're likely to encounter. Rob Eisenberg: So it's pretty simple. When we were building a lot of apps and looking at the way other people were building a lot of apps, we noticed that people followed a very simple naming convention. If they have like a customer edit ViewModel, they would typically have a customer edit View. So they were doing some manual work to instantiate the two and to set the DataContext and Transcription by PWOP Productions, http://www.pwop.com Page 6 of 13
ind them together and so on and so forth. So what we said is, "You know, this is a convention that we feel comfortable with. We see a lot of other people are using it already. Let's embed this into the framework and let the framework do it for us." So with ViewModel-first in Caliburn.Micro, when your app starts, we actually don't load up a RootVisual or a window or anything like that, WPF. What we actually do is we ask you for your ViewModel, and once we find your ViewModel we then, via convention, find the View that goes with that and then we data-bind them together for you and then after that we apply a series of conventions over the bindings as well. We could talk about that; it’s where it gets really interesting. But that's where you see the ViewModel-first behavior come into play in the framework and that's where you see that first convention, and it's just a simple naming convention. You can actually organize your solution in a lot of different ways. A lot of people like to group their views in a namespace and their ViewModels in another namespace. I personally like to organize my solutions by feature. But however you do it, the basic naming convention literally can match them together like that and it's just a little bit of boilerplate code. But if you're building larger and larger apps, it’s code you don't have to write, you can follow that convention, and you know from the get-go this is how I'm going to assemble my solution. Much like in ASP.NET MVC, you have a naming scheme and organizational scheme for where you put your controllers and where you put your Views and how all that works. Carl Franklin: Right. Rob Eisenberg: The framework can do a lot for you. So it’s the same sort of concept but with Model- View-ViewModel. Carl Franklin: And the ViewModel binder is probably the next thing that you're going to come into contact with? Rob Eisenberg: Yeah. So that’s the piece that's actually does this. Once we locate the View and we have your ViewModel, we then bind them together and that's the simple process of setting the DataContext at first, but then we go and we apply a bunch of other conventions and all these are namebased conventions. You can turn them on or off if you're uncomfortable with the notion of conventions like this. But we do some pretty simple things. So for example, if you have a button named “Save” in your View and your ViewModel has a method named “Save”, we’ll assume via convention that you want the clicking of the button to execute that message, so we’ll automatically wire those up. Carl Franklin: Nice. Rob Eisenberg MVVMs Us with Caliburn.Micro! February 17, 2011 Rob Eisenberg: Additionally we can do this with data binding. So if you have a textbox named FirstName and you have a property on your ViewModel called FirstName, we’ll automatically wire them up and we'll do this in an intelligent way such that if we see that your property has getters and setters, we'll automatically make the data binding a two-way data binding. If we see that your ViewModel implements IDataErrorInfo, we’ll automatically turn validation on on the data binding. Carl Franklin: Nice. Rob Eisenberg: So we can do a lot of things like that. We can even apply string conversion and value converters in the data binding automatically. Carl Franklin: Wow. Rob Eisenberg: It’s built to be sort of as intuitive as we can make it. Again a lot of people really, really love it. It tends to be a polarizing thing. You either really, really love this idea and you see how much time it can really save you and how much simpler your markup can be as a result, or you're just uncomfortable with its kind of magical ability. Richard Campbell: And this is all about names, right? This is about naming conventions to make this all work. Carl Franklin: Right. Rob Eisenberg: And you can turn it on and off at the framework level or on a per-view basis. I have a lot of people that say, “well, what about the performance of these kinds of things,” and I generally say, well, I haven't seen any problems with that but for productivity sake start building your app with conventions on and if you find a View that has some sort of performance issue, just turn conventions off on that one View and go back to manually wiring everything. You can always do all these things manually. But if you don't have to and if the conventions fit your way of development, then you can save a lot of time. Carl Franklin: I'm trying to figure out how using a convention will degrade performance. Rob Eisenberg: Well, there's a little bit of reflection that happens in the background to inspect your ViewModel. Carl Franklin: Okay. Rob Eisenberg: But there's actually quite a bit of reflection happening anyway in the data-binding system and in various other places. Transcription by PWOP Productions, http://www.pwop.com Page 7 of 13
Page 1 and 2: HTTP://www.dotnetrocks.com Carl Fra
Page 3 and 4: Pandhi, our resident graphics and A
Page 5: Rob Eisenberg: The blue screen. Tha
Page 9 and 10: Rob Eisenberg: It's got a simple ba
Page 11 and 12: Rob Eisenberg: But each one them wo
Page 13: Carl Franklin: Am I right in assumi

dotnetrocks 0638 rob eisenberg

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

Delete template?

Save as template?