\\[Editor’s note: Welcome to “.NET Rocks Conversations,” excerpts of conversations from the .NET Rocks! weekly Internet audio talk show. Hosts Richard Campbell and Carl Franklin chat with a wide variety of .NET developer experts. This month’s excerpt is from show 533, “Phil Haack Introduces MVC 2.”\\]
Carl Franklin: Our guest today is none other than Mr. Phil Haack. Phil is a program manager with the ASP.NET team working on ASP.NET MVC. His blog is at haacked.com. We're here to talk about some meat and potato stuff here. ASP.NET MVC v2.
Richard Campbell: Phil, am I delusional here? Is MVC uptake been better than anybody expects it?
Phil Haack: It's hard for me to get a real numbers on what the uptake is, but we've had some really large customers take it as well as some very cool startups who are using it. I don't have any concrete numbers but just from an anecdotal experience, I think the uptake has been quite good.
Campbell: I always had the sense that the technology was going to receive lots of good critical acclaim. Folks that are really serious about development and methodologies think that we're going to like it a lot, but that it would be challenging enough to actually build apps in that it may not be the first choice for a lot of folks.
Haack: I think when a lot of people hear the words Model-View-Controller and MVC Pattern, they start to think, “Oh, this is very highfaluting architectural level stuff.” But it turns out that the project templates and the pattern that we've implemented for that is just a small part of the actual ASP.NET MVC Framework. I it's actually simpler if you started off as a web developer, rather than using some other framework like Web Forms where you kind of use it in response and request. If you came from a VB 6.0 background, then it is a very jarring transition. I started off using classic ASP; I find the model pretty simple. We're seeing a lot of developers adopting MVC because once they get the pattern they really like it. They find that they're closer to the markup, and they can understand what's going on under the hood a little better.
Franklin: Well, let's talk about DRY, "Don't repeat yourself," this whole idea of write it once and that's it. This is something that MVC really allows you to do. Talk about separation of concerns.
Haack: It's about trying to keep logic in one place where it belongs so that you're not repeating view logic within your model, or your model logic within your view. This is also just general stuff like anytime you see yourself repeating a code block in effect, just refactor that into a method and call that method.
Franklin: Yeah.
Haack: It's the symbol of DRY. But then there's the “separation of concerns DRY” where you're really focused on having the logic in the right place.
Franklin: Is it safe to say that REST is everywhere, or RESTful architecture is everywhere in MVC?
Haack: You know, I think REST is orthogonal to the MVC pattern but the MVC Framework generally has REST-like elements. However, one thing that we have on our CodePlex site that was developed in partnership with the WCF team, which is the Windows Communication Foundation team, is the REST for MVC. So if you go into our CodePlex MVC 1.0 site, which is aspnet.codeplex.com, you'll see that there's a separate download there, REST MVC.
Franklin: It's not like you're going to throw away any if you have web services. Now you're just going to use MVC to write web services.
Haack: Regarding web services versus MVC, I often see that if you're building an app and you're writing a little service specifically for your app, and you're not doing inner app communications, then it's a lot easier and quicker just to throw up a controller that returns some JSON or some XML, especially JSON. Like when I'm writing simple apps, and I'm using jQuery to do asynchronous calls back to the server to get some more data, I just throw up a controller that returns a JSON result, and boom, I'm done. When I would switch to a full-blown service is when I need external clients to communicate with my service, and I need security boundaries and all that extra stuff that goes into maintaining a real service.
Franklin: In my experience most of the time in the business world you're writing Windows to Windows services, you don't need all that stuff that web services gives you.
Haack: Yeah, a lot of times it's just an HTTP Get and use a return or response and you're done. The guy on the other end is just left to parse it. Every single service you integrate with is going to have a different thing, and so you just have to deal with it all.
Franklin: Can we jump into some of the meat of the framework? Maybe start with the strong typing for input helpers and link helpers?
Haack: Sure. One of the new features in MVC 2.0 is what we call Strongly-typed Helpers. They're the expression-based versions of what we've had before, such as text. Whereas we had TextBox and I said drop-down list, now we have the equivalents for what we use in naming convention TextBox 4.0 or TEXTAREA 4.0, and the argument you pass the TextBox 4.0 is a Lambda Expression. So I might just base on the current model. If you have a strongly-typed view page, you can use TextBox 4.0 and you might pass M such that with a little arrow M.First Name. Let's say your model is a typed product or user that has a first name. Under the hood is we'll look at that expression, and we'll actually look at the model and evaluate the first name property value. That's going to be the value that we render out. Now, with that we have the ability to look at any metadata applied to that property via Data Annotations, and you might be able to control other things. Now our TextBox Helpers currently do a whole lot with metadata, but we have this separate set of Strongly-typed Helpers that we call Template Helpers. Template Helpers take the expression-based syntax to the next step, which is let's say instead of me having to declare specifically which input I want to use, I don't want to use a TextBox here or a TEXTAREA, I can just say "You know what? I wanted you to give me an editor for a product." So you might do HTML.Editor for M such that M.Product, let's say another product property. So we actually look to see if there's a Product.ASCX Editor template and if there is, we'll use that to render out a form for editing the current product. That form might have fields for every single property or just a select a group of properties. If there is no Product.ASCX, let's say you've forgot to add the product template, we'll actually default to a default object template. That object template simply uses reflection and a set of rules to figure out which properties to show. We try to avoid certain properties like collection. We're not going to build a collection editor for that right in line. So we'll just show most of the simple properties and allow you to edit it. The Template Helpers makes it very nice to build quick user interfaces, sort of like runtime scaffolding, but it also allows you to maintain consistency. One example: you can register an editor for the daytime type and that editor might use your custom date picker like some kind of JavaScript data picker so that every time you use Editor 4.0 on any type and it has the property of date/time, we'll use the date/time date picker. So it's incorporating features that those of you who use Dynamic Data would be very familiar with. They're very similar to field templates in Dynamic Data.
Campbell: Which is funny because I always thought Dynamic Data and MVC were diametric opposing designs. MVC was supposed to be super light and very testable, and Dynamic Data was going to be super easy to build stuff quickly.
Haack: They're not as diametrically opposed as people might realize. We're all one team here, and we do a lot of idea sharing. So for example, Routing, which is originally developed for ASP.NET MVC, actually became its own feature and was incorporated in Dynamic Data. Dynamic Data has its own routes that are built on top of Routing. Likewise, we took some of the ideas of Dynamic Data but we modified them for the MVC world. So it's not quite as automatic as Dynamic Data because we want to put the developer in control, but it allows you to do these things that are quite productive in MVC that still fit the MVC paradigm.
\\[There’s much more: To listen to or read the full interview go to www.dotnetrocks.com.\\]
