ASP.NET MVC Preview 3
The Gu has announced another regular drop of ASP.NET MVC. This one is Preview 3 and the goodness can be found at the http://www.asp.net/mvc/ landing page.
How does this relate to Visual Studio 2008/.NET 3.5 SP1 Beta
It doesn't. For now ASP.NET MVC is an out-of-band Web downloadable thing. It's bin deployable (meaning you don't HAVE to put them in the GAC) and you don't even need to tell your hosting/ISP. They are what they are - three DLLs in a folder. Bam. Phil has more details on his blog from last week with regard to MVC Preview 2, but the idea still holds. He says:
"MVC Preview 3 will not be affected by having SP1 installed. Preview 3 will include newer privately versioned bin deployable builds of the Routing and Abstractions DLLs. That way these assemblies will not be affected by the versions in the GAC installed by SP1, because they will have different version numbers."
Cool.
ASP.NET MVC Preview 3 Beginner Videos
I did two quick updated beginner introductory videos specific to Preview 3, but the original Preview 2 videos are still up and still mostly valid. As I've said before, there will be more videos as we get closer to release. These are safe to show your CTO and they are short - on purpose - so he or she doesn't fall asleep.
Introduction to ASP.NET MVC Preview 3
Scott Hanselman walks you through an ASP.NET MVC Hello World example in this video updated for Preview 3. He also explains the lifecycle of an ASP.NET MVC application.
Basic Application Building with ASP.NET MVC Preview 3
Scott Hanselman uses a sample database to create a basic Product Catalog management application with create, read, update and delete functionality. You can download the source for this application at Phil Haack's blog.
One cool new development is that my team added Rob's Storefront Videos to the http://www.asp.net site and you can check out the first ten videos here. The benefits are several, first, Rob won't have to pay for bandwidth, but we've also transcoded his videos into a bunch of formats for those of you that are passionate about your specific format. You know who you are. Me, I use just WMV or MP4 (DivX/xVid) and think that that's one too many, but you've can you choose from WMV, Zune, iPod, PSP, MPEG-4, and 3GP if it make you happy.
Updated ASP.NET MVC Preview 3 Sample
Phil has updated the Northwind MVC Sample for ASP.NET MVC Preview 3 and you can get it at Phil's Blog.
Preview 3 is also makes it way easier to test Controllers because they return ActionResults now, which gets the Controller out of the call stack and lets the Test focus on what the controller really intends to do, rather than worrying about mocking side effects of what the Controller might have done. As usual ScottGu has left me with nothing good to write about because he's already done a fine post with lots of detail on the changes. So selfish! ;)
BTW, if you're digging the Gu's black code theme, blame me for converting him and go check out the Visual Studio Programmer Themes Gallery, I believe he's still using Rob Conery's Textmate Take 2 theme.
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
Not sure if this is the right place to ask a question about the pros and cons of using the Asp.net MVC framework.
I have not looked at it yet but just read few articles.
I have googled but failed to find some sort of indication/General rules on when to use this framework and when not to use it.
EG
I am starting a new Asp.net Application would you use the MVC Framework or go for the normal approach.
Why should I use it compared to using your own custom MVC pattern?Or the Web Client software factory approach.
Should I convert an existing application to an MVC Framework .Is it worth it?
etcc..
Basically i am just trying to understand if when writing a new asp.net app this is the way to go and the benefits it gives outweighs the cons you might have by using the "old" approach if you like
Sorry for being generic but any indication on when it's appriopriate to use would be helpful.
Gabriel
It is great that the MVC binaries are bin deployable right now. I would like to see it remain this way, as I can see several opportunities to use ASP.NET MVC on client side applications (for web apps and more). However, I suspect that the plan is for MVC at some point to require a FULL .NET 3.5 SP1 installation. Is that a correct assumption?
If it is, I would like to lobby for either...
1. Keeping ASP.NET bin deployable
or...
2. Getting the BCL team to add the binaries to the .NET client profile install.
I have emailed the BCL team about option 2. However, I see that they have cut the web assemblies from the .NET Framework Client Profile so I am not holding out much hope...
It would be great to here the skinny on option 1, or any thoughts you may have on the topic.
Congrats on shipping this release.
Ben
I think Scott is still in bed (I hear he sleeps between 4 and 4.45 am) so I will chime in.
If you already know how to build "ASP.NET classic" applications AND you don't know why you would want to use ASP.NET MVC, I would stick with what you know. However, if you have time, you could do some proof-of-framework POC work with ASP.NET MVC and see how you go.
General guidance I have seen has included the following suggestions:
-Use ASP.NET MVC if you want full unit testing coverage for your web application.
-Use ASP.NET MVC if you want FULL control over your HTML.
-Use ASP.NET MVC if you like to talk about "separation of concerns" and "inversion of control" (this rule is a joke).
-Don't use ASP.NET MVC if you need to use a load of existing ASP.NET server controls that you have written or could buy.
My 2 pence worth.
Ben
Thanks a lot for your post.This is exactly the kind of things I am looking for. "A generic guide of what the Asp.net MVC is meant for".
I will of course play with the examples provided,but it's nice to know on what basis you should use it.
thanks again.
ie. I tried to run the Northwind preview 3 sample and I get errors about signing of the assemblies.
Even when I remove and try to reference the new installed assemblies, I get these errors.
The installation preview 3 works, but not this demo.
I do not have this SP installed, maybe I should install it?
I've also seen it mentioned that you won't want to use MVC if you are also incorporating winform apps into your solution. Though I've never read why...
Ryan,
Are you saying that if you want to have a winform app in the same solution as the Asp.net MVC you cannot have it?
Ben - You rock, thanks for jumping in and helping out. Question, though. Why would you want MVC in the *client* install? It's a server-side thing.
However, if you came to the web from hand-coding HTML/CSS/Javascript (which I did for nearly 10 years before ever writing any C# or VB.NET and environments like Perl, PHP, Python, etc. on the web, then the whole ViewState and postback model are quite foreign and ASP.NET MVC is much more familiar.
While I've been doing ASP.NET for a few years now, only when I sat down with MVC did I finally feel like things worked like I was wishing they did. I can make forms post where I want them to, hook AJAX/Javascript directly to elements without going around dynamic ID's, etc.
In short, ASP.NET has always felt like a foreign language, no matter how much of it I "spoke", where MVC feels like a "native" language already despite being new.
Sorry, confusing use of the word client. I will try and explain more clearly.
There is a class of applications that are installed on a users desktop machine (what I meant by client) but which present a web interface. Most I have seen (and written) embed Cassini, and use Cassini to serve up an ASP.NET application to the user. I first saw this (ages ago) when the MS CRM guys used this technique (think it was for some sort of offline capability).
I would like to be able to do the same thing with ASP.NET MVC, i.e. write an application that a customer can download and install on their desktop machine which serves up a an ASP.NET MVC website to them (i.e. my app). There are good reasons for doing this (e.g. the app they installed they will use from a browser from different places in their home or office). If ASP.NET MVC requires a 200mb framework download, this usage scenario will not be possible.
Did I explain that any better!
Ben
The article I'm looking for implied more that there were issues with reuse of business objects and the controllers than some kind of incompatibility...looking for it now.
Here's the quote:
Winform and Webform (cross-boundary application)
These are applications that need to be built to run on a web page as well as a winform. Good examples of these are applications where 100% of the functionality is available in house, on a winform, and 90% of the functionality is available on a webpage to external users. In these cases the MVP passive view pattern should always be used. The reason is the presenter is always responsible for everything. Thus, all you have to do is build respective UIs (that implement a particular interface) and you can resuse the whole M and P from the MVP model. It provides great reuse of code.
Here's the link to the whole article entitled "Choosing a UI Pattern (MVC, MVP, and ASP.Net MVC)"
Ben - Gotcha. Take a look at the weekly source code last week...you can even run IIS7 sites in your own process, and you can certainly just xcopy deploy MVC and use it. I don't see why it's a choice between a the two framework installers.
I guess what I am asking is this...
Will the first *release* of ASP.NET MVC have any dependencies on .NET assemblies that are only part of the FULL install of .NET 3.5?
...or put another way...
Will the final release of ASP.NET MVC run on a box that only has the .NET Framework Client Profile installed?
I know that today the answer would be Yes to both, as the only GAC'd 3.5 assembly reference is System.Core (which is part of the .NET Client Profile). However, do you know if this will change in the future? For example, as System.Web.Routing is being pushed into the core BCL, will you (at some point) remove the binary from the "ReferencedAssemblies" folder and start referencing the GAC'd version? If you do, then it scuppers my cunning plans (I think) as this assembly is not part of the .NET Framework Client Profile.
It may well be that I am being a right donut, and missing something obvious here. If so, let me know and I will go and lie down in the corner for a while.
Ben
I don't know if this answers your question.
Thanks for the note and thanks for pointing out the System.Web.Extensions dependency. I was using an NDepend dependency analysis list, and for some reason it was not detecting that assembly (probably user error).
Yes, it does answer my question. The answer is No. the official release of MVC will not work on a box with only the .NET Framework Client Profile on it (as they are not shipping System.Web.Extensions in the RTM). However, assuming the MVC source is still on CodePlex at release time (and you have not liberally sprinkled it with non-CP 3.5 dependencies) I should be able to
Thank you both for the time and info, much appreciated.
let's do our best to keep this world 善.
I read this blog post http://blog.rodj.org/archive/2008/03/31/activerecord-the-asp.net-mvc-framework.aspx that is specific to ActiveRecord stating that a TypeConverter can be used for this purpose. I am not using ActiveRecord but I thought maybe the TypeConverter concept would apply anyway. I have been unsuccessful with the TypeConverter so far.
I am on the right track with the TypeConverter or should I be doing something else?
1) Why are all of the demo's reverting back to the old "ASP Classic" model of putting all of the programming in the HTML instead of in the code behind? Is it just to faciliate the presentation of the demos (not have to switch to the code behind all the time) or is there another reason?
2) How does the MVC lend itself to to the use and creation of server controls? I would say that over 90% of the work I do is on server controls not so much as on the pages themselves. In fact, most of our pages end up just being a wrapper over server controls.
3) While I really like the concept of routing, what level of control do you do to handle the data hiding from the URL generation?
4) How does this work in a secure environment? I gave not seen anything to handle switching from a "public" (http://) site to a "secure" (https://) site.
David
1. "all of the programming" isn't in the View, it's in the Controller. The code you're seeing in the View is just supposed to look at the model and display it. There should be minimal code in a View and no business logic.
2. Phil is working on the control stuff, but I suspect there will also be a partial rendering style of doing things also.
3. I'm not sure I understand that question.
4. Good question. I'll ask Phil.
David Fauber - It's up to the NUnit team to add that support in like the xUnit.NET and mbUnit folks have. I'm not sure what the status is with that but we've contacted CharlieP on the NUnit Team.
For 1) what I was talking about is the demos that I have seen (yours and Rob's) seem to do a lot of the UI coding in the aspx file using <% %> tags instead of handling it in the code behind aspx.cs file. It seems to me that this a step backwards. Am I missing something?
For item 3) I think that I must be missing something in the concept of routing. One of the big things that we got with VeiwState, ControlState and the Session objects was the concept of not passing vital information on the URL using parameters. It seems to me that the whole idea of the way that the routing works is to put this information back on the URL. For instance, you end up with an URL like http://localhost:1111/product/Appairal/Boots1 in the clear, which could end up allowing someone to try an DOS attack by just spamming the site to guess the items.
David
"Am I missing something". Yes, I think you are probably missing an understanding of the MVC pattern. It is fine to have code in the view, if that code is for generating your view. Your business logic code is in your controller (you could see this as your code behind, sort of).
It is not really a step backwards. It is an alternative to the current ASP.NET framework. If you like ASP.NET better you can keep using it.
ViewState, ControlState and Session objects don't do anything to prevent DOS attacks. And guessing the URLs of products on an ecommerce site is a good thing! Are you for real or are you a troll?!
I am for real. I am trying to understand the implementation conciderations of a new architecture. I use the MVC pattern everyday to separate the view of a domain model from its implementation - otherwise testing is a nightmare.
Yes, for an e-commerce site, guessing the URL is a good thing. However, I would hope that this pattern is not for just e-commerce sites. If for instance, the site is a banking site, I would not want to have more information on the URL than the name of the site. By the use of a VeiwState varable I can carry the account being processed for instance without exposing it on the URL. The way the demos for this imply, I would be carrying as part of the URL.
Concider for a minute how easy it would be for a script monkey hacker to spam the site looking for information. If I (the monkey) see that http://localhost/A/B/1 is one thing, then all I would have to do is spin a simple dictionary call to every letter/word for each of A and B, as well as the first 1.000,000 numbers for each. I would think that preventing this would be a good thing.
The other concern that I was attempting to bring out is the use of <% %> tags in generating the dynamic parts of the view in the demos. This is very much an old school, "ASP Classic", style of programming. I would hope that, if I was to use this architecture, I am not to abandon the last 10 years of best practices. This architecture is implemented in ASP.NET, therefore, I want to continue using ASP.NET along with it. I understand that all of the business logic is in the controller. However, most of the site's I have worked have a great deal of UI logic in the code behind to generate the dynamic portions of the screen. I would not want to be forced to move that code into the designer (HTML) file via <% %> tags.
David
All of your requirements are met by the ASP.NET you have today. Plus you like the existing architecture. Therefore, you should carry on using it. It is a choice. However, while some think Viewstate is clever like a fox, others think it is a pox. ;)
As for the bank example, would one of the following suffice?
1. Put the account number in a secure session cookie.
2. Encrypt the account number on the URL.
At then end of the day, it is choices. ASP.NET MVC is extensible, so if you don't like the way the views work you can write your own "Code Behind View Engine"!
I have watched all your webcast you done on mvc. Now I have a request. can you please provide a comprehensive tuitorial on how to setup asp.net mvc on IIS. I think this will help lot of people from the community who have started thinking building real web application using asp.net mvc. Please consider my request.
Thank you so much.
Hassan.
I have a MVC application in the throws of building. It is a nearly completed product, just adding new functionality.
I love MVC and using it with SubSonic just makes my life so easy in enhancing functionality and being confident it all works.
It would be great for you to have a look at it even in it's uncompleted state. Let me know if you are interested.
Steve
Comments are closed.
Confused in SoCal,
Ryan