ASP.NET PostBack is Dead, Long Live PostBack
August 12th, 2008ASP.NET MVC is gathering a lot of interest and while it is an alternative to the PostBack model we have come to know the past several years MVC is not meant to replace PostBack. There is a lot that the coming MVC framework will facilitate and I plan to leverage it, but I am also interested in continuing to use PostBack on some pages where WebForms are working just fine as is.
Tonight Jeff Palermo is presenting TDD, DI, and SoC with ASP.NET MVC at 7pm at Direct Supply. Already there are over 100 people registered which is much more than we normally see at a monthly presentation. Attendance is even more than the AJAX presentations, which has to say something.
It is going to be an interesting night and I hope to get some insight into how I can leverage MVC in future applications. I have some ideas and some of what I have seen with MVC makes me uncomfortable, but the presentation tonight may bring me around.
August 14th, 2008 at 9:30 am
I am not new to .NET, but new to MVC. If we have a tiered asp.net model where we have our presentation layer, and then our business layer that the presentation layer interacts with, can we simply use the MVC model strictly for the presentation layer (.aspx pages, etc.) and it not affect the business model? I guess what I'm understanding is MVC is strictly for how your web forms call data or process back end code, etc.
Also, how does this replace the postback? We have a site where we sale cable ties and we have a few pages where postback is really slow and causes issues with orders, etc. If we could use something other than the postback model it would be great. We changed it to use Ajax so at least the customer knows something is happening while the postback is happening, but still have issues due to some browsers not supporting Ajax.
August 14th, 2008 at 11:36 am
MJ,
The PostBack model is tied to the controls model in ASP.NET which helps you avoid dealing with query parameters. For example, you have a TextBox named TextBox1 and access the value of that control as TextBox1.Text. With MVC you would just place the raw markup for the input tag onto the page and access the value as a query parameter (Post or Get). This removes a few layers of abstraction that TextBox. If you like hand writing HTML (and I do) then you will prefer this model.
But you are right that you can still have a class library or set of class libraries that handle all of your data access and business logic and put an ASP.NET frontend on it, or a WinForm or Console application. You could even move from an PostBack web site model to MVC with limited changes. What I see too much is tons of code in the code-behind which implements business logic and data access. The biggest problem there is that functionality in web pages is not portable or reusable. At least if I place the functionality to save a business object to the database in a class library I can perform the exact action across multiple pages.
I was impressed with Palermo's presentation. It was the very first time that I saw an architecture that made IoC make sense. He was also convincing with TDD although the mocks still is hard for me to fully appreciate. My unit tests tend to be integration tests which involved the database, so making the leap to TDD will be a big one for me.
What was interesting about the MVC presentation was that his architecture, which pulls the infrastructure (the moving parts) out of the core of the application, is not compatible with the new Entity Framework. The EF generates the business objects and the data access in one big piece but MVC wants the business objects to be defined as a permanent and reusable structure and have the data access injected into the controller. This way the data access implementation can be changed without rewriting the entire system. And normally when a large application has to be rewritten is because the underlying technology changed, not the way the business works. In that sense it seems that MVC and IoC facilitate long lived applications where EF is basically the new version of Typed DataSets that we know and love. (not really)
It is good to know that I can completely decide not to learn EF now and instead focus on the other major technologies that will be much more worthwhile for the projects I will be working on over the next 3 years.
August 14th, 2008 at 12:08 pm
MJ,
For AJAX, look at using web services (ASMX and SVC) as JavaScript objects. You can do this by decorating the services with attributes and adding the services to the ScriptManager. I use this a lot. Then your JavaScript can interact with the web services to push data back and forth. I use that to avoid pushing around lots of HTML and ViewState in UpdatePanels. Like with one site I need to do a variation of the thumbs up/down that you see on Digg. I did that with a service call to submit the user's vote and used the JavaScript to adjust the HTML to reflect the change. It sends 1 byte of data and is very quick.
September 3rd, 2008 at 3:26 pm
Brennan,
I'm not sure JavaScript will work in this case. I can see using web services possibly, but we still have the issue with postback. The problem with using JavaScript is I would have to completely change the ordering system. Our cable tie application ordering system is built using a 5-tier approach. We have presentation, user process, business, business data and database. The presentation does nothing but talk to user process or business, but its all in postback. I'm not sure using JavaScript with our model would be the best solution. I'm just not sure. I'll have to look more into that approach. However, web services might be possible, because I could just link the web service with our user process and business layers.
Anyway, thanks for getting back with me. I'm still scratching my head on this one.
MJ