We recently opened up a new ASP.NET CodePlex Project that we will be using to provide previews (with buildable source code) for several upcoming ASP.NET features and releases. Last month we used it to publish the first drop of the ASP.NET MVC source code. This first drop included the source for the ASP.NET MVC Preview 2 release that we shipped at MIX, along with Visual Studio project files to enable you to patch and build it yourself. A few hours ago we published a refresh of the ASP.NET MVC source code on the site. Th... lire la suite
We recently opened up a new ASP.NET CodePlex Project that we will be using to provide previews (with buildable source code) for several upcoming ASP.NET features and releases. Last month we used it to publish the first drop of the ASP.NET MVC source code. This first drop included the source for the ASP.NET MVC Preview 2 release that we shipped at MIX, along with Visual Studio project files to enable you to patch and build it yourself. A few hours ago we published a refresh of the ASP.NET MVC source code on the site. This source refresh is not an official new ASP.NET MVC preview release - instead it is an interim drop that provides a look at the current state of the source tree. We will ship the official "ASP.NET MVC Preview 3" release in a few weeks after we finish up some more work (more features and tweaks to existing ones, better VS tool integration, VS express edition support, documentation, etc). If you are someone who wants a hassle-free installation of ASP.NET MVC to use that ships with documentation and full tool support you'll probably want to wait for this official preview release. If you are someone who wants a chance to see an early "preview of the preview" and have the opportunity to start using and giving feedback on some of the features immediately, today's source refresh is probably interesting to look at. Improvements with this ASP.NET MVC Source Refresh This week's update (which you can download here) includes a number of improvements to ASP.NET MVC. Some of these include: In addition to posting the source code for the ASP.NET MVC framework, we are also posting the source code for the unit tests that we use to test it. These tests are implemented using MSTest and the open source Moq mocking framework. A VS 2008 project file for the unit tests is included to make it easy to build and run them locally within your VS 2008 IDE. Creating a New ASP.NET MVC Project You can build your own copy of the ASP.NET MVC assemblies by downloading the MVC source and compiling it locally, or alternatively you can download a VS Template package to get a pre-built version of them along with a Visual Studio project template that you can use to quickly build a new ASP.NET MVC Project that uses the latest bits. After you install the ASP.NET MVC source refresh .VSI template, a new "ASP.NET MVC Application" project template will show up under the "My Templates" section of your "New Project" dialog: This new "My Templates" version of the MVC project template lives side-by-side with the previous ASP.NET MVC Preview 2 release (which you can see above it in the main project templates section of the dialog). This allows you to safely create new projects and and use both the latest source version and the last official preview version on the same machine. When you create a new project using this updated ASP.NET MVC Project template you'll by default get a project that looks like below: Controller Changes with this ASP.NET MVC Drop If you were reading the above code closely you might have noticed a few changes with how Controller classes are by default implemented using this new ASP.NET MVC source refresh drop. With the ASP.NET MVC Preview 2 release the above HomeController action methods would have instead been implemented like below: The MVC feature team is experimenting with a few ideas in this week's drop and are trying out some new ideas: It is pretty easy to update existing Controller classes built with Preview 2 to use this new pattern (just change void to ActionResult and add a return statement in front of any RenderView or RedirectToAction helper method calls). So why change Controller action methods to return ActionResult objects by default instead of returning void? A number of other popular Web-MVC frameworks use the return object approach (including Django, Tapestry and others), and we found for ASP.NET MVC that it brought a few nice benefits: It will enable some nice Asynchronous execution scenarios in the future. Action methods will be able to return an AsyncActionResult object which indicates that they are waiting on a network operation and want to yield back the worker thread so that ASP.NET can use it to execute another request until the network call completes. This will enable developers to avoid blocking threads on a server, and support very efficient and scalable code. One of the goals with this interim preview is to give people a chance to play around with this new approach and do real-world app-building and learning with it. We will also post an alternative Controller base class sample that you can use if you still prefer the previous "void" action return approach. We deliberately didn't include this alternative Controller base class in this source refresh drop, though, because we want to encourage folks to give the "ActionResult" return approach a try and send us their app-building feedback on it. Note: with this week's source drop you still need to use mocking to test the TempData property on Controllers. Our plan is to not require mocking to test this with the ASP.NET MVC Preview 3 drop in a few weeks. URL routing rules within ASP.NET MVC applications are typically declared within the "RegisterRoutes" method of the Global.asax class. With ASP.NET MVC Previews 1 and 2 routes were added to the routes collection by instantiating a Route object directly, wiring it up to a MvcRouteHandler class, and then by setting the appropriate properties on it to declare the route rules: The above code will continue to work going forward. However, you can also now take advantage of the new "MapRoute" helper method which provides a much simpler syntax to-do the same thing. Below is the convention-based URL route configured by default when you create a new ASP.NET MVC project (which replaces the code above): Note: with this week's source drop you need to pass-in the controller and action parameters (in addition to the Category param) to the Html.RouteLink() helper to resolve the correct route URL to generate. The ASP.NET MVC Preview 3 drop in a few weeks will not require this, and allow you to use the Html.RouteLink call exactly as I've written it above to resolve the route. This week's MVC source drop also supports a bunch of new URL route mapping features. You can now include "-", ".", ";" or any other characters you want as part of your route rules. ASP.NET MVC Preview 2 introduced wildcard route rules. For example, you can indicate in a rule to pass all remaining URI content on as a named parameter to an action method: These wildcard routes continue to work fine with this week's preview - and are very useful to look at if you are building a blogging, wiki, cms or other content based system. Note that in addition to using the new routing system for ASP.NET MVC scenarios, we are also now using the same routing system within ASP.NET Dynamic Data (which uses ASP.NET Web Forms). Hopefully the above post provides a quick update on some of the new features and changes exposed with this week's ASP.NET MVC source update drop. You can download it here if you want to start using it immediately. Alternatively, you can wait a few weeks for the official ASP.NET MVC Preview 3 drop - which will have some more features (and incorporate feedback people provide on this week's drop), deliver a more seamless installer, provide nice VS integration, and deliver up to date documentation. For any questions/issues with this week's drop of ASP.NET MVC, make sure to also check out the ASP.NET MVC forum on www.asp.net.
Last month I blogged about our ASP.NET MVC Roadmap. Two weeks ago we shipped the ASP.NET Preview 2 Release. Phil Haack from the ASP.NET team published a good blog post about the release here. Scott Hanselman has created a bunch of great ASP.NET MVC tutorial videos that you can watch to learn more about it here. One of the things I mentioned in my MVC roadmap post was that we would be publishing the source code for the ASP.NET MVC Framework, and enable it to be easily built, debugged, and patched (so that you can work around any bugs you encounter without having to wait for the next preview refresh release). Today we opened up a new ASP.NET CodePlex project that we'll be using to share buildable source for multiple upcoming ASP.NET releases. You can now directly download buildable source and project files for the ASP.NET MVC Preview 2 release here. Building the ASP.NET MVC Framework You can download a .zip file containing the source code for the ASP.NET MVC Framework for the release page here. When you extract the .zip file you can drill into its "MVC" sub-folder to find a VS 2008 solution file for the project: Double-clicking it will open the MVC project containing the MVC source within VS 2008: When you do a build it will compile the project and output a System.Web.Mvc.dll assembly under a \bin directory at the top of the .zip directory. You can then copy this assembly into a project or application and use it. Note: the license doesn't enable you to redistribute your custom binary version of ASP.NET MVC (we want to avoid having multiple incompatible ASP.NET MVC versions floating around and colliding with each other). But it does enable you to make fixes to the code, rebuild it, and avoid getting blocked by an interim bug you can't work around. Our plans are to release regular drops of the source code going forward. We'll release source updates every time we do official preview drops. We will also release interim source refreshes in between the preview drops if you want to be able to track and build the source more frequently. We are also hoping to ship our unit test suite for ASP.NET MVC in the future as well (right now we use an internal mocking framework within our tests, and we are still doing some work to refactor this dependency before shipping them as well). Filed under: ASP.NET, .NET, Community News, MVC
Go grab the source code! Scott Guthrie announced the availability of the ASP.NET MVC Framework Source on CodePlex late last week. What is the ASP.NET MVC Framework? MSDN Magazine has a timely article on this very hot topic: If you are interested in learning more about the ASP.NET MVC Framework, our friend Peter Laudati, will be showcasing ASP.NET MVC Framework at our FREE conference in about a month (we'll also have the latest on Silverlight 2, ASP.NET AJAX Security and Design Patterns, SQL Server Data Services, and more). Seating is limited, please register today! ASP.NET MVC Framework - Peter Laudati ASP.NET MVC provides a framework that enables you to easily implement the model-view-controller (MVC) pattern for Web applications. This pattern lets you separate applications into loosely coupled, pluggable components for application design, processing logic, and display. ASP.NET MVC is not a replacement for Webforms. It provides an alternative choice when designing a Web application. We’ll explore the advantages ASP.NET MVC offers, including how:
La version 2 des Asp.Net Extensions est disponible et embarque des nouvelles versions de notre ASP.NET MVC, mais aussi ADO.NET Services, ...
Scott Guthrie viens d'annoncer la mise a disposition de l'Asp.Net MVC Framework sur Codeplex.
ASP.NET MVC Source Code Now Available - ScottGu's Blog ASP.NET - Home (CodePlex) Thoughts on ASP.NET MVC Preview 2 and Beyond 역시나 예고된대로 ASP.NET MVC Framework (Preview 2)의 소스코드가 공개되었습니다. 이번에 공개된 소스코드는 어셈블리들 중에서 System.Web.Mvc.dll에 해당하는 부분이며, 수정하여 만든 dll의 재배포는 허용하지 않습니다. 이는 이전의 다른 소스코드 공개와 마찬가지로 Framework의 이해와 디버깅, 버그 수정등 개발에 도움이 될 수 있는 방향의 의미로의써의 공개라는 목적을 가집니다. 물론, .NET Framework 소스코드 공개 방식과 마찬가지로 소스서버를 통한 공개도 이뤄집니다. 차후에는 CodePlex에 Preview 공개 여부와 상관없이 소스컨트롤을 통해서 지속적인 check-in을 할 예정이고, Unit Test들을 추가하여 공개할 예정입니다.
The ASP.NET MVC team is in the final stages of finishing up a new "Preview 4" release that they hope to ship later this week. The Preview 3 release focused on finishing up a lot of the underlying core APIs and extensibility points in ASP.NET MVC. Starting with Preview 4 this week you'll start to see more and more higher level features begin to appear that build on top of the core foundation and add nice productivity. There are a bunch of new features and capabilities in this new build - so much in fact that I decided I needed two posts to cover them all. This first post will cover the new Caching, Error Handling and Security features in Preview 4, as well as some testing improvements it brings. My next post will cover the new AJAX features being added with this release as well. Action Filter Attributes are a useful extensibility capability in ASP.NET MVC that was first added with the "Preview 2" release. These enable you to inject code interceptors into the request of a MVC controller that can execute before and after a Controller or its Action methods execute. This enables some nice encapsulation scenarios where you can easily package-up and re-use functionality in a clean declarative way. Using a filter within a ASP.NET MVC Controller is easy - just declare it as an attribute on an Action method, or alternatively on the Controller class itself (in which case it will apply to all Action methods within the Controller): Previous preview releases of ASP.NET MVC enabled this filter extensibility, but didn't ship with pre-built filters. ASP.NET Preview 4 now includes several useful filters for handling output caching, error handling and security scenarios. The [OutputCache] filter provides an easy way to integrate ASP.NET MVC with the output caching features of ASP.NET (with ASP.NET MVC Preview 3 you had to write code to achieve this). To try this out, modify the "Message" value set within the "Index" action method of the HomeController (created by the VS ASP.NET MVC project template) to display the current time: When you run your application you'll see that a timestamp updates each time you refresh the page: Now when you hit refresh on the page you'll see that the timestamp only updates every 10 seconds. This is because the action method is only being called once every 10 seconds - all requests between those time intervals are served out of the ASP.NET output cache (meaning no code needs to run - which makes it super fast). In addition to supporting time duration, the OutputCache attribute also supports the standard ASP.NET output cache vary options (vary by params, headers, content encoding, and custom logic). For example, the sample below would save different cached versions of the page depending on the value of an optional "PageIndex" QueryString parameter, and automatically render the correct version depending on the incoming URL's querystring value: You can also integrate with the ASP.NET Database Cache Invalidation feature - which allows you to automatically invalidate the cache when a database the URL depends on is modified (tip: the best way to-do this is to setup a CacheProfile section in your web.config and then point to it in the OutputCache attribute). The [HandleError] filter provides a way to declaratively indicate on a Controller or Action method that a friendly error response should be displayed if an error occurs during the processing of a ASP.NET MVC request. By default when you point your browser at this URL, it will display a default ASP.NET error page to remote users (unless you've gone in and configured a section in your web.config file): Visual Studio now automatically adds a default "Error" view template for you inside the \Views\Shared folder when you create new ASP.NET MVC Projects starting with Preview 4: Declaring an [Authorize] attribute like above indicates that a user must be logged into the site in order for them to request the "About" action. When non-logged-in users attempt to hit the /Home/About URL, they will be blocked from gaining access. If the web application is configured to use Windows based authentication, ASP.NET will automatically authenticate the user using their Windows login identity, and if successful allow them to proceed. If the web application is configured to use Forms based authentication, the [Authorize] attribute will automatically redirect the user to a login page in order to authenticate (after which they'll have access): The [Authorize] attribute does not have a dependency on any specific user identity or role management mechanism. Instead it works against the ASP.NET "User" object - which is extensible and allows any identity system to be used. To help you get started, though, the ASP.NET MVC Project Template in Visual Studio now includes a pre-built "AccountController" and associated login views that implement a forms-authentication membership system with support for logging in, logging out, registering new users, and changing passwords. All of the views templates and UI can be easily customized independent of the AccountController class or implementation: The AccountController class that is added to new projects uses the built-in ASP.NET Membership API to store and manage user credentials (the Membership system uses a provider API allowing any back-end storage to be plugged-in, and ASP.NET includes built-in providers for Active Directory and SQL Server). If you don't want to use the built-in Membership system you can keep the same AccountController action method signatures, View templates, and Forms Authentication ticket logic, and just replace the user account logic within the AccountController class. For the next ASP.NET MVC preview release we are planning to encapsulate the interaction logic between the AccountController and the user identity system behind an interface - which will make it easier to plug-in your own user storage system (without having to implement a full membership provider) as well as to easily unit test both it and the AccountController. One last improvement to touch on in this first preview 4 post is some improvements being made on the Controller class that allow you to more easily unit test the TempData collection. The TempData property allows you to store data that you want to persist for a future request from a user. It has the semantic of only lasting one future request (after which it is removed). It is typically used for MVC scenarios where you want to perform a client-side redirect to change the URL in the browser, and want a simple way to store scratch data. With previous ASP.NET MVC Previews you had to mock objects in order to test the TempData collection. With Preview 4 you no longer need to mock or setup anything. You can now add and verify objects within the Controller's TempData collection directly within your unit tests (for example: populate a controller's TempData property before calling its action method, or verify that the action updated the TempData after the action returned). The actual storage semantics of the TempData collection is now encapsulated within a separate TempDataProvider property. Hopefully the above post provides a quick look at a number of the new features and changes coming with ASP.NET MVC Preview 4. My next post on ASP.NET MVC Preview 4 will cover the new AJAX functionality that has been added, and demonstrate how to take advantage of it. Filed under: ASP.NET, Visual Studio, .NET, MVC
Here is the latest in my link-listing series. Also check out my ASP.NET Tips, Tricks and Tutorials page and Silverlight Tutorials page for links to popular articles I've done myself in the past. Displaying the Number of Active Users on an ASP.NET Site: Scott Mitchell continues his excellent series on ASP.NET's membership, roles, and profile support. In this article he discusses how to use ASP.NET's Membership features to estimate and display the number of active users currently visiting a site. ASP.NET Dynamic Data Update: The ASP.NET team last week released an update of the new ASP.NET Dynamic Data feature. This update adds several new features including cleaner URL support using the same URL routing feature that ASP.NET MVC uses, as well as better confirmation, foreign-key, and template support. ASP.NET Testing with Ivonna: Travis Illig blogs about a new testing framework named Ivonna that enables unit testing of ASP.NET web forms. ASP.NET AJAX ASP.NET AJAX UI Templates: Nikhil Kothari from the ASP.NET team has a cool post that shows off a prototype he has been working on that enables clean client-side AJAX templating of UI. ASP.NET AJAX Control Toolkit TabContainer Theme Gallery: Matt Berseth has another of his excellent posts - this one shows off a bunch of cool themes you can use to style the TabContainer control in the ASP.NET AJAX Control Toolkit. Why do ASP.NET AJAX page methods have to be static? Dave Ward has a useful article that talks about the page methods feature in ASP.NET AJAX, and explains why they are static methods. ASP.NET MVC Inversion of Control, ASP.NET MVC and Unit Testing: Fredrik Kalseth has a cool article that talks about the concepts behind inversion of control (IOC) and how you can use this with ASP.NET MVC to better isolate dependencies and enable better unit testing of your code. Stephen Walther's ASP.NET MVC Talk: Stephen Walther delivered a many-hour ASP.NET MVC post conference talk at ASP.NET Connections last week. You can download his slides + demos for free. Also check out his previous posts on Unit Tests with Visual Studio 2008 and TDD with Rhino Mocks. MVC Contrib Project Update: Eric Hexter blogs about some of the latest updates to the open source MvcContrib project to work with the latest ASP.NET MVC interim source release. Testing Action Results with ASP.NET MVC: Jeremy Skinner blogs about some cool extension method helpers he has added to MvcContrib to enable pretty sweet testing of Controller actions. MVC Membership Starter Kit - 1.2 Release: Troy Goode has posted an update to his excellent MVC Membership Starter Kit. This version works with the interim ASP.NET MVC source release.
This past Thursday the ASP.NET MVC feature team published a new "Preview 5" release of the ASP.NET MVC framework. You can download the new release here. This "Preview 5" release works with both .NET 3.5 and the recently released .NET 3.5 SP1. It can also now be used with both Visual Studio 2008 as well as (the free) Visual Web Developer 2008 Express SP1 edition (which now supports both class library and web application projects). Preview 5 includes a bunch of new features and refinements (these build on the additions in "Preview 4"). You can read detailed "Preview 5" release notes that cover changes/additions here. In this blog post I'm going to cover one of the biggest areas of focus with this release: form posting scenarios. You can download a completed version of the application I'll build below here. Basic Form Post with a Web MVC Pattern Using the previous "Preview 4" release of ASP.NET we might have implemented the above scenario using a ProductsController class like below that implements two action methods - "Create" and "Save": The "Create" action method above is responsible for returning an html view that displays our initial empty form. The "Save" action method then handles the scenario when the form is posted back to the server. The ASP.NET MVC framework automatically maps the "ProductName" and "UnitPrice" form post values to the method parameters on the Save method with the same names. The Save action then uses LINQ to SQL to create a new Product object, assigns its ProductName and UnitPrice values with the values posted by the end-user, and then attempts to save the new product in the database. If the product is successfully saved, the user is redirected to a "/ProductsAdded" URL that will display a success message. If there is an error we redisplay our "Create" html view again so that the user can fix the issue and retry. Form Post Improvements with Preview 5 One way to work around these issues is to publish a single "/Products/Create" URL, and then have different server logic depending on whether it is a GET or POST request. One common approach used to-do this with other web MVC frameworks is to simply have a giant if/else statement within the action method and branch accordingly: ASP.NET MVC "Preview 5" now offers a better option to handle this scenario. You can create overloaded implementations of action methods, and use a new [AcceptVerbs] attribute to have ASP.NET MVC filter how they are dispatched. For example, below we can declare two Create action methods - one that will be called in GET scenarios, and one that will be called in POST scenarios: Model Binders in ASP.NET MVC are classes that implement the IModelBinder interface, and can be used to help manage the binding of types to input parameters. A model binder can be written to work against a specific object type, or can alternatively be used to handle a broad range of types. The IModelBinder interface allows you to unit test binders independent of the web-server or any specific controller implementation. Model Binders can be registered at 4 different levels within an ASP.NET MVC application, which enables a great deal of flexibility in how you use them: 1) ASP.NET MVC first looks for the presence of a model binder declared as a parameter attribute on an action method. For example, we could indicate that we wanted to use a hypothetical "Bind" binder by annotating our product parameter using an attribute like below (note how we are indicating that only two properties should be bound using a parameter on the attribute): Note: "Preview 5" doesn't have a built-in [Bind] attribute like above just yet (although we are considering adding it as a built-in feature of ASP.NET MVC in the future). However all of the framework infrastructure necessary to implement a [Bind] attribute like above is now implemented in preview 5. The open source MVCContrib project also has a DataBind attribute like above that you can use today. 2) If no binder attribute is present on the action parameter, ASP.NET MVC then looks for the presence of a binder registered as an attribute on the type of the parameter being passed to the action method. For example, we could register an explicit "ProductBinder" binder for our LINQ to SQL "Product" object by adding code like below to our Product partial class: 3) ASP.NET MVC also supports the ability to register binders at application startup using the ModelBinders.Binders collection. This is useful when you want to use a type written by a third party (that you can't annotate) or if you don't want to add a binder attribute annotation on your model object directly. The below code demonstrates how to register two type-specific binders at application startup in your global.asax: 4) In addition to registering type-specific global binders, you can use the ModelBinders.DefaultBinder property to register a default binder that will be used when a type-specific binder isn't found. Included in the MVCFutures assembly (which is currently referenced by default with the mvc preview builds) is a ComplexModelBinder implementation that uses reflection to set properties based on incoming form post names/values. You could register it to be used as the fallback for all complex types passed as Controller action arguments using the code below: Note: the MVC team plans to tweak the IModelBinder interface further for the next drop (they recently discovered a few scenarios that necessitate a few changes). So if you build a custom model binder with preview 5 expect to have to make a few tweaks when the next drop comes out (probably nothing too major - but just a heads up that we know a few arguments will change on its methods). You might wonder - what is up with this redirect when we are successful? Why not just redisplay the form again and show the success message? The reason for the client-redirect is to ensure that if the user hits the refresh button after successfully pressing the save button, they don't resubmit the form again and get hit with a browser prompt like this: Doing the redirect back to the GET version of the action method ensures that a user hitting refresh will simply reload the page again and not post back. This approach is called the "Post/Redirect/Get" (aka PRG) pattern. Tim Barcz has a nice article here that talks about this more with ASP.NET MVC. In this week's Preview 5 drop the UpdateModel methods always work against the Request object's Form post collection to retrieve values. This means that to test the above form post action method you'd need to mock the request object in your unit test. With the next MVC drop we'll also add an overloaded UpdateModel method that allows you to pass in your own collection of values to use instead. For example, we would be able to use the new FormCollection type in preview 5 (which has a ModelBuilder that automatically populates it with all form post values) and pass it to the UpdateModel method as an argument like so: Basic Form Entry Error Handling and Input Validation with ASP.NET MVC With earlier preview releases of ASP.NET MVC the above code wouldn't be enough to deliver a good end-user experience (since it wouldn't highlight the problem, nor preserve user input if there was an error). Developers can explicitly write code to add items into the ModelState collection within their Controller actions. ASP.NET MVC's ModelBinders and UpdateModel() helper methods also automatically populate this collection by default when they encounter input errors. Because we were using the UpdateModel() helper method in our Edit action above, when it failed in its attempt to map the UnitPrice TextBox's "gfgff23.02" input to the Product.UnitPrice property (which is of type Decimal) it automatically added an entry to the ModelState collection. You can customize the appearance of the the error css classes to look however you want. The default CSS error rule for input elements in the stylesheet created in new ASP.NET MVC projects looks like below: ASP.NET MVC supports any data layer abstraction (both ORM and non-ORM based), and allows you to structure your domain model, as well as associated rules/constraints, however you want. Capabilities like Model Binders, the UpdateModel helper method, and all of the error display and validation message support are explicitly designed so that you can use whatever preferred data access story you want within your MVC applications (including LINQ to SQL, LINQ to Entities, NHibernate, SubSonic, CSLA.NET, LLBLGen Pro, WilsonORMapper, DataSets, ActiveRecord, and any other). There are several patterns and approaches we could take to integrate richer business rules to the Product model object we've been using above: we could define the rules within the object, or external from the object. We could use declarative rules, a re-usable rules engine framework, or imperative code. The key point is that ASP.NET MVC allows us to use any or all of these approaches (there aren't a bunch of features that require you to always do it one way - you instead have the flexibility to reflect them however you want, and the MVC features are extensible enough to integrate with almost anything). Integrating the above Rules into our ASP.NET MVC UI Once we've implemented our business rules, and exposed our RuleViolations like above, it will be relatively easy to integrate it into our ASP.NET MVC sample. Once we do this, we can re-run our application. Now, in addition to seeing input format related error messages, ASP.NET MVC's validation helpers will also display our business rule violations as well. This post has provided a quick look at how form post scenarios work with ASP.NET MVC Preview 5. Hopefully after reading it you have a better sense of how you handle form and input entry scenarios using a MVC model. You can download a completed C# version of the application I built above here. I will post a VB version a little later this week (it is unfortunately 4:30am while I'm typing this and I need to hop on a plane in a few short hours and have not started packing yet). Important: If you don't like the MVC model or don't find it natural to your style of development, you definitely don't have to use it. It is a totally optional offering - and does not replace the existing WebForms model. Both WebForms and MVC will be fully supported and enhanced going forward (the next release of ASP.NET WebForms will add richer URL routing features, better HTML markup/client-side ID/CSS support, and more). So if after reading the above post you think "hmm - that doesn't feel natural to me", then both don't worry, and don't feel like you should or need to use it (you don't). In my next post on MVC I'll cover how to integrate AJAX into your ASP.NET MVC applications. Filed under: ASP.NET, .NET, Community News, MVC
This morning we released the Preview 3 build of the ASP.NET MVC framework. I blogged details last month about an interim source release we did that included many of the changes with this Preview 3 release. Today's build includes some additional features not in last month's drop, some nice enhancements/refinements, as well as Visual Studio tool integration and documentation. You can download an integrated ASP.NET MVC Preview 3 setup package here. You can also optionally download the ASP.NET MVC Preview 3 framework source code and framework unit tests here. ASP.NET MVC Preview 3 includes the MVC Controller changes we first discussed and previewed with the April MVC source release, along with some additional tweaks and adjustments. Preview 3 also now supports using an approach where you return an "ActionResult" object that indicates the result of the action method, and enables deferred execution of it. This allows much easier unit testing of actions (without requiring the need to mock anything). It also enables much cleaner composition and overall execution control flow. Note that in addition to support a "ViewResult" response (for indicating that a View should be rendered), ASP.NET MVC Preview 3 also adds support for returning "JsonResult" (for AJAX JSON serialization scenarios), "ContentResult" (for streaming content without a View), as well as HttpRedirect and RedirectToAction/Route results. The HTML helper methods have been updated with ASP.NET MVC Preview 3. In addition to a bunch of bug fixes, they also include a number of nice usability improvements. With previous preview releases you needed to always explicitly pass in the value to render when calling the Html helpers. For example: to include a value within a element you would write: You'll also start to see ASP.NET AJAX helper methods show up in future preview releases as well, which will make it easier to integrate AJAX into MVC applications with a minimum of code. ASP.NET MVC Preview 3 includes a number of improvements to the URL routing system. URL routing is one of the most "fundamental" components of a web MVC framework to get right, hence the reason we've spent a lot of focus the first few previews getting this area nailed. Our new URL routing engine will ship in .NET 3.5 SP1 this summer, and will support both Web Forms and MVC requests. ASP.NET MVC will be able to use the built-in .NET 3.5 SP1 routing engine when running on .NET 3.5 SP1. ASP.NET MVC will also include its own copy of the assembly so that it can also work on non-SP1 systems. Some of the URL Routing Improvements in the Preview 3 release include: ASP.NET MVC Preview 3 includes new "MapRoute" and "IgnoreRoute" helper methods that you can use to more easily register routing rules. MapRoute() provides an easy way to add a new MVC Route rule to the Routes collection. IgnoreRoute() provides an easy way to tell the URL routing system to stop processing certain URL patterns (for example: handler .axd resources in ASP.NET that are used to serve up JavaScript, images, etc). Below is an example of the default RegisterRoutes() method within Global.asax when you create a new ASP.NET MVC project where you can see both of these new helper methods in action. ASP.NET MVC Preview 3 also supports a bunch of new URL route mapping features. You can now include "-", ".", ";" or any other characters you want as part of your route rules. ASP.NET MVC Preview 3 also supports wildcard route rules (these were also in Preview 2). For example, you can indicate in a rule to pass all remaining URI content on as a named parameter to an action method: Today's Preview 3 release of ASP.NET MVC includes a bunch of improvements and refinements. We are starting to feel good about the URL routing and Controller/Action programming model of MVC, and feel that those areas are starting to bake really well. In future preview releases you'll start to see more improvements higher-up the programming model stack in areas like Views (html helpers, validation helpers, etc), AJAX, sub-controllers and site composition, deeper Login, Authentication, Authorization and Caching integration, as well as data scaffolding support. I also have a (very) long tutorial post that I started putting together this past weekend that walks-through building an application using ASP.NET MVC Preview 3 that I'm hoping to wrap up and post in the next few days. This should provide both a good intro to ASP.NET MVC, as well as help provide some context on how all the pieces fit together if you are interested in using the ASP.NET MVC option. Filed under: ASP.NET, .NET, Community News, MVC