\\[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.
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?
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.\\]