Functionality is missing in this version

Topics: Developer Forum, User Forum
Aug 14, 2009 at 3:15 PM
Edited Aug 14, 2009 at 3:29 PM

Although there are some places where AJAX has been implemented (which did not require MVC), the functionality in this version of TBH is less than the 1.0 version.

First when editing ecommerce items, article categories, etc., you can no longer upload images.  You still have a place to input the image url, but the upload option is now missing.

In Forums, if you select the thread title to view it you get a "Specified cast is not valid" error.  Okay, this is a bug not reduced functionality, but the last version didn't ship with errors in major use cases of the system.

Forum profile settings are missing (signature and avatar image).

All of the modularity functioanlity from web parts appears to be msising.  I can no longer add to the system by adding web parts.  Specifically I had added a content web part that allowed content to be added to the site without having to alter the page.

Health monitoring is also missing.  Was this removed becasue of MVC?  Did anything else take its place?

What exactly were the advantages of going with MVC that make up for this reduced functioanlity?




Aug 15, 2009 at 2:42 PM

Hi there,

There were a few things that got overlooked when we developed the MVC version.  First was, that there was no defineable way to upload files when we developed and wrote these module chapters.  So we would have had to invent it on our own which would be obsolete now that the framework was released.  The file upload feature was added pretty late in the preview releases, and the two chapters forums and ecommerce were done pretty early.

Second we decided not to impliment the forums as a direct to direct copy of each other.  You will notice that the current forums look a lot like vs forums.  This was by design, to bring the forum module up to web 2.0 style.  Second avatars were outsourced to, if you read the forum section of the book we talk specifically about this.

Your right the bug shouldn't have been there, and we are releasing an update to fix that in the next couple of weeks.  See my previous post about this.

Web parts do not work in MVC and as far as I know from the MVC team web parts will never work as defined by Microsoft web parts.  However if you find a way to add web parts from the .NET framework working with MVC I will be happy to add it.  I couldn't find a way.

Also health monitoring, in my oppinion, was a dead technology on arrival when 2.0 was released.  So there is no reason to include it again.  It is a very poor implimentation of event tracking, and doesn't really meet business needs.  So that is why it wasn't included.

Also if you have to ask what the advantages are over web forms, please read chapter 2 and 3, they do an excelent job laying it out.


Aug 16, 2009 at 4:10 AM

I do not have my hands on the book yet, but it should be arriving soon. 

What I'm struggling with in evaluating MVC is determining when it is an appropriate technology over a three teir design with web forms.  So far, MVC has been falling short.  It seems that MVC is just forcing developers to implement a separation in business logic from UI that they frankly should have been doing anyway.  Being able to unit test the control classes isn't really a benefit since they are calling the business logic tier that has unit tests already.  There seem to be a lot of disadvantages to using MVC  such as no databinding and the inability to use a variety of .Net controls.  The UI development appears to take considerably longer compared to webforms because it reduces the usefulness of your RAD tools. 

I was hoping that your book would give some guidance in this area as it shows an application implemented with both technologies.  After all the book is Prolem-Design-Solution, and the problem hasn't changed, so I assumed that there would be reasons why MVC was chosen over web forms to solve this problem.  Maybe when I get the book and pay particular attention to chapters 2 & 3 this will be more apparent.  From an initial inspection it appears that features were given up simply for the sake of using the MVC framework without any real gain from this.  The file upload is an example.  This was a requirement of the application that wasn't delivered because the framework didn't support it.  In a real world scenario would you have given this up or gone with a different technology?  Even more disapointing was that when I load tested the two versions (using the original version of each, not including my own modifications), the 1.0 version had better perfomance.  I might have been willing to give up features in exchange for increased performance.

I personally replaced the monitoring in the 1.0 version with the logging application block from enterprise library.  I wasn't surprised that the health monitoring wasn't in 2.0 as much as that it hadn't been replaced with something else.  One of the reasons I liked the first book so much was that it did a great job of showing a real world application from the ground up.  I even deployed this application in production with very few modifications (well very few initially) and thanks to the book I had a deep understanding of the application's design.  But I wouldn't consider deploying an application in a production environment without some type of event tracking and error reporting.

So far in evaluating MVC, the only scenario I've found where it has a clear advantage is in the use case of delivering different content to mobile users.  Being able to return an entirely different view based on the type of mobile device has possibilities, but whether this is signficantly better than directing them to a separate mobile site that has mobile pages using adapters remains to be seen.


Aug 16, 2009 at 1:57 PM

Looks can be decieving, I have built to date 9 MVC applications and have come to discover the following. With both MVC and Webforms, once you pass the initial learning curve, take aproximately the same amount of time to build. In webforms you are able to quickly build web pages by dragging and dropping controls onto the page but you lose time in having to tie in those controls in your code behind files. This can be data binding them or handling their on click events, or on selected item change. In contrast with an MVC Framework application you have to create by hand the html you want to render but you don't have to fool around with a code behind file. Basic posts and gets are used to communicate data back and forth to the controller. Your controller methods can also accept instance of your model, and it automagically maps all the data from the post to the appropriate model variables if your naming conventions match. The mapping alone saves you a ton of time.

The other huge advantage I discovered was MVC Framework applications are much simpler to maintain. All of the action methods in my applications have a HandleError attribute flag which on error gets all the important information and sends out an email to me. There are also attribute flags for securing my controller methods, so my delete user method only works for admins but my register user works for everyone. In this way you won't really need health monitoring since you can crete your own notification service very easily.

The MVC Framework applications also had much fewer code to do the same things. Part of this was due to the fact there was no need to map inputs, nor was there a need to create interaction methods such as onclick() because this was handled inside the view. You'd be suprised at how chunky those code behind files can get, even with the best of intentions.

Lastly there is a performance boost to be gained as well. When you run a webforms application those user controls may rely on the session state or have complex javascript needed to be able to run. Big culprits of using up tons of session state is the grid control which in MVC is replaced by a simple table with no state to maintain. A guilty party for using excessive javascript is the update panel. I was a big fan of it at first but when you dump complex controls into it such as a grid control, things get very hairy very fast. In contrast with the MVC Framework application you would create your own javascript by hand using a framework such as jQuery which would offer a much lighter weight solution. If your ever curious take a look at the amount of data sent over from our MVC Beerhouse application and Marco's old application, you may be suprised. Firebug is great for determining these thigns. I think you will also have noticed that there is far, far less coding we did for this project than was done in the original BeerHouse application. Again an advantage of the MVC Framework.

So to sumerize, you will be doing less coding, have greater control over your html, have faster web applications, and spend a lot less of your time maintaining the application. If that sounds like something you'd be interested in, the MVC Framework might be for you :D.

Aug 17, 2009 at 9:07 AM

If I were going to say build even a simple UI, lets say for a corporate contact application (yes I'm picking one I've built for a client recently).  I have a tree control on the which lists the contacts in the organization heiarchy and initially a search area on the right.  The contacts in the tree should fill the initial level, but only fill additionally levels when it is expanded.  The view for each contact consists of the image of the contact, their HR information retrieved from the SAP system and a separate tab for each category of profile that was configured for the system by the administrator.  In each tab, the answers to profile questions are displayed.  The content for each tab is updated using AJAX.  The user can select an option to edit their profile in which case the questions are displayed with a different display for each type of question (radio buttons for multiple choice, text boxes for open ended questions, etc.). 

The questions were actually built out using a repeater control and using a open source questionnaire library whereas the rest of the interface was built using Infragistics.  This took two days to build out and connect to the business layer generated with .Net tiers.  I'm not sure where I would even begin trying to build out this in raw HTML and I'm quite sure it would take considerably longer than two days to build out the javascript required for the user interface.  I'm quite frankly amazed that you haven't run into timing issues when developing a UI with any level of sophistication.  In the application above the field verification is in the entitty layer of .Net tiers and security checks were made in the business objects.  Events are logged using the logging application block from Enterprise library from the business tier.  Security checks are likewise made using application roles (managers can edit their subordinates profiles) in the business tier.  Security attributes have been around for business objects long before MVC.  Even if I were building an MVC application, this is where they belong as I might be using these same objects later in a desktop application.  The tree control has view state turned off (as would any grid control I used, shame on you if you use view state with grids).  Error information displays automatically with controls since I've implemented the IDataError interface in my entities.  Two way databinding sends the form information to my business tier through the object datasource without me having to do anything manually.  There is plumbing code to handle errors used through a common base class for forms in the application.

Don't get me wrong, I know MVC is a great design pattern for applications since I have used an MVC pattern with desktop applications for years.  My previous attempts at MVC with ASP.Net centered around using Workflow Foundation and creating a base page class as the controller and each view inheriting and calling methods on the base class.  Although I was surprised that Workflow Foundation wasn't used in the routing, I was very impressed with the object model used with ASP.Net MVC, in particular action methods and automatic parameter mapping.  When evaluating ASP.Net MVC I made the following initial observations:

  1. The Model is exactly like the DAL I already implement.  As a matter of fact in the first ASP.Net MVC application I built I used the DAL I already had.
  2. The View is the equivalent of the win or web form and is used to display the data delivered by the controller.
  3. The Controller in this framework is what handles view delivery and calls the business tier.  This is where a lot of people disagree with me, and say this is essentially the business layer of the application, but since the business tier in an enterprise application is typically shared among multiple applications I don't believe you should put business logic directly in the controller.  Its responsibilities should be confined to retrieving the appropriate data from the model (or rather the business logic layer) and returning the appropriate view.

I think part of my frustration with ASP.Net MVC is that using server controls in no way violates anything related to the MVC pattern.  After all in a desktop application (whether win foms or WPF) binding is used all the time to display the data delivered from a controller.  As long as the view is used to display the entities given it by the controller and the action controls call actions on the controller the application is nice, neat and maintainable.  The server controls restriction in ASP.Net MVC sounds more like a technical restriction based on the postback mechanism rather than a design one, but its being pitched as a feature.

I've picked up on ASP.Net MVC much faster than I had expected.  Its actually kind of funny, when coding in ASP I had a library that I used for developing forms.  This library consisted of a group of functions that would do a response.write html out to the page based on the type and field name I passed in.  It built an array of field elements as the form was built for which elements were required that was used in javascript to verify the form and then again to verify the data at the server.  I had no problems adjusting to building forms in MVC because it was so close to how I did it back in the ASP days (and still do for a few clients).  Funny how things come full circle.  The model and controller classes are only marginally different than what I have used in desktop MVC frameworks.

I like the HandleError attribute or rather the concept of action filters in general.  In ASP.Net MVC doesn't the HandleError simply display an Error view either from the controller folder or the shared folder?  How would this send an email?  I could see building out a custom action filter that would send notifications, but I haven't been able to figure out exactly how to override the HandleError action filter.  I also wasn't able to find code in the Beer House that does this, nor could I find a Error view in either the shared or view folders so I assumed that a default error behavior was being used.  I will certainly give it another look as customizing the HandleError is on my TODO list for learning ASP.Net MVC.

I really think you are giving server controls a bad rap.  Certainly they can be abused.  But unless the javascript is being embeded in the page, it only has to be downloaded once so the network cost here is minimal.  Even with the complicated javascript in the Infragistics controls (and believe me if I were using the Infragistics web grid the javascript would be very heavy) the network tax is light.  Your are right the application would probably perform better if I wrote all the javascript by hand, but I would spend weeks doing this for a marginal gain.  The time you save coding on the back end you are going to take up in coding javascript.  So far, I haven't seen any MVC applications with anything other than a very basic UI and I can't help wonder if this isn't the reason.  As for viewstate, since the introduction of control state in ASP.Net 2.0 it is much easier to turn viewstate off (which I do whenever possible).

Also, if you wanted to use lighter controls in webforms, you certainly can.  I have worked with apps that render tables direclty instead of using grids for exactly the reason you mention.  But when you need to deliver a feature, its nice to have the option.  Any code base can get chunky, and in reviewing some of the attempts to build portals with widgets using MVC I've seen some VERY chunky code (this is prior to the PartialRendering.  Certainly webforms can be coded poorly.  I could code all the business logic in my code behind instead of using a business tier (of course then no one would hire me).  I could set attributes on my controls instead of using CSS (I might get hired, but the guilt would drive me nuts).  But there is a good reason people use these server controls, it saves tons of time having to code html and javascript by hand and if used properly has a marginal cost.

As for performance boost, the Beer House does not have better performance with MVC.  I ran a load tester against both applications simulating 50 users.  Although the performance was close, actual pages delivered went to the 1.0 version.  If the pages themselves are lighter, performance is being lost somewhere else.

To summarize, there is no right or wrong in design, there are only advantages and disadvantages.  I love parameter mapping, routing, and action filters in MVC whereas I love having the option to use server controls or not in web forms.  I disagree that there is less code in MVC vs web forms.  For the forums in the Beer House, the code in MVC including javascript is 549 lines as opposed to 507 in the 1.0 version.  With some exceptions your code has just moved.  Also, lets not forget that it has fewer features.  Add the modularity/web parts support to the 2.0 version and then see if it has less code.  If your UI is sophisticated you may actually have to write more code due to the javascript.  I also disagree with having better control over your HTML as you could code the html the same way in web forms as you are doing in MVC you're just not required to.  The code itself is more maintainable in MVC (a fact that has panned out when following the pattern in desktop applications).  The ability to add views for specific situations while using the same controller makes code much more straightforward and easier to follow.  An example would be delivering a different view based on the mobile device type.  This would require redirects and duplication of event code in a web forms application, but its trivial to implement and makes for a much better user experience in a MVC application.  Making the application faster by writing the javascript and using html primitives can be done in either web forms or MVC, but having to do all the HTML from scratch in MVC makes developing any sophisticated UI more time consuming (otherwise server controls would never have been invented in the first place).  You tend to have to code the same thing over and over in MVC that would be encapsulated in a server control in web forms (such as when you have multiple tabs on a page that update using AJAX).  The development experience is much better in web forms vs MVC as in web forms you have WYSIWYG support for the server controls and there is no WYSIWYG support for the helper methods.  But the biggest disadvantage to ASP.Net MVC is that you lose what may be a huge investment in both time and money in control libraries.

I personally don't see where the advantages of ASP.Net MVC make up for giving up server controls and from a political standpoint I don't see being able to tell a client that I just can't use their $1000 - $3000 investment in server controls when I build their application.  I noticed that Telerik has released controls for MVC and I'm interested in seeing how these pan out and what other vendors follow suit.  I haven't heard of any such plans from either Infragistics or Component One (are they still called that?).  While I would prefer to use MVC, I will likely need to find a MVC framework for ASP.Net that does not have this limitation.

Aug 17, 2009 at 1:14 PM

I just want to correct one thing you said two posts ago.  File uploading was not removed from MVC, there just wasn't an easy method to get it working when we did the articles/blog/news chapter.  I could have jumped through hoops to get file uploading working, because after all it is just HTTP data which works the same across every programming language, but back in May 2008, when I was coding this module, the path I would have went down to support file uploads would have incurred a ton of technical debt, that I wasn't willing to at the time of the project because of all the future unknowns.  If you want to upload a file now all that you need to do is:

public ActionResult Upload(HttpPostedFileBaseModelBinder file) { ... }

To address the other point you mentioned, I would be interested to see how you load tested the applications and what tools you used, because by every bodies independent tests of MVC is many folds faster than WebForms.  And to be honest we aren't doing anything out of the norm.  So post up how you got your results so that I can mirror and confirm, because my own tests show that the MVC version is many times faster than the dated Web Forms version.

To address your second post, in my world there are 3 types of web programming on the .NET framework, there is MVC, ASP.NET WebForms, and plain ASP.NET, you can think of the second two as with controls and without controls respectively.  You are right the classic ASP.NET WebForms without controls is very fast and in fact that is what the views in MVC are built off of, so you are always going to get better performance than MVC using ASP.NET WebForms without controls, because you don't have the controller structure overhead.  However to build any business application that is easy to maintain you have to build some sort of backend structure to manage those pages, and MVC just formalizes some of that application layer structure to make most of that necessary plumbing easy.

Also like everything else, you have to use MVC in the right situation.  Inside the firewall it is a toss up between MVC and WebForms, outside the firewall I believe MVC has the advantage.  But to counter your point about asking them to give up 3K worth of server controls, wouldn't it be worth giving up those 3K of server controls if it led to better performance, less maintainability, and better verification and testing of the code?  I mean if a programmer has to waste 4 days on a WebForms project where they wouldn't have had to on MVC, the adoption of MVC has already paid for it self, give what programmers are paid.


Aug 17, 2009 at 3:37 PM

With the beerhouse you have to keep something in mind. We purposefully kept things very simplistic to reduce the learning curve for you the consumer. That means some javascript was a lot more drawn out than it needed to be, and some of our code was elongated or purposefully kept simple to help you better understand. If this wasn't a learning tool jQuery, YUI, and EXT would of been used in conjunction with a number of plugins such as jQuery.Validate, jQuery.Autocomplete, th EXT Grid, jQuery.Rating and many others). That would of also greatly reduced our hand written code base. Plus once you get the hang of javascript and using jQuery its pretty natural and doesn't take weeks to put together. I typically only spend 30 minutes putting together very precise and effective javascript. Again a learning curve.

I would be very interested in seeing your results as well on the performance of the new BeerHouse website. My tests as well have shown huge improvement. If we had some additional time we could of implemented the new caching action filters which are fantastic. That would of given huge performance bonus I am sure. I guess the whole MVC movement in genral of late is geared around giving you the developer a lot more control over what is happening. User Controls although nice represent for many a black box. As you know all manner of perversions of programming can arise when developers think things are happening "magically". The big advantage WebForms has over MVC Framework at this point is maturity, there are a lot more infrastructure put into place for them at the time being. Of course the same was true for VB6 many years ago and we all know where that led.

If you are really sticking to your guns on this and want to put your money where your mouth is I am willing to do a a small codeoff to prove my point. It would make a great blog entry for me if you are interested in the challenge. Let me know.



Aug 17, 2009 at 7:17 PM

Server controls are used for one reason and one reason only, they decrease the initial development time.  In most cases there is a performance cost paid for this, but in a world where the deadlines are tight and the initial ramp up time often determines whether the project gets done or not, that performance cost may be acceptable.

I'm using WAST to simulate the load (an old tool I realize, but it still works).  When you mentioned inside verses outside the firewall, I decided to rerun my load test from my ISP.  My initial tests were done against my intranet server from a workstation and the results were close with 1.0 being the winner by a small margin.  I posted both versions to my ISP and ran the tests against it and MVC won out with a 80% decrease in overall load time.  Since my internet connection is through satellite, I assume the bottleneck must be from something being accessed in the 2.0 version from outside the server that slows the system down on my intranet.  This actually makes me feel much better about the framework, but I might want to track down and remove the bottleneck if I ever run TBH as an intranet site.  If performance were my primary consideration, I would almost certainly choose MVC.  I can send you the WAST script if you like.

You make a good point on the transition from VB6, but a lot of people didn't make that transition until their vendors came out with .Net controls.  Another more recent example has been trying to get customers to move from winforms to WPF.  Until Infragistics came out with their WPF suite I had no luck doing this even with the benefits of application styling.  Moving to the Smart Client Application block was less of a challenge because they didn't have to give anything up to do it.  I'll admit that I get really frustrated with developers that don't want to know how their controls work and end up delivering pages overflowing with viewstate unnecessarily.  A question I haven't thought to ask is why server controls aren't supported in MVC.  I had assumed that it was because of the postback model, but I shouldn't assume that is the case.

BTW, I still can't find where you customized the HandleError action filter.  Did this maybe not make it into the initial 2.0 version?

I would be interested in some published best practices in developing the presentation portion for MVC applications.  I have used YUI in the past, but typically have been able to deliver a better user experience using Infragistics.  I have not used EXT.  I also agree that there were a number of places where I expected to see jquery used in TBH that it wasn't used.  I would definitely be interested in a code challenge where we each develop a sophisticated UI and compare for initial ramp up time, performance and ease of use.  It would give me a much better handle on MVC and would give me a selling point when pitching the ASP.Net MVC to my customers. (well, assuming that MVC comes out on top :) ).

Aug 17, 2009 at 10:09 PM

I'm glad to hear I wasn't losing my mind with the performance issues. Internal networks can be tricky as there is literally no latency. At any the MVC Framework has been a really strange experience for me personally. At times I feel like I am almost on the other side of the fence from my webform only brothers. Believe it or not there are tons and tons of really great javascript controls that you can use, and that have been used for years in php.

EXT has been a great resource for grid controls ( but they have much more. The great thing about the MVC Controllers is they kick out all sorts of data whether it be for mobile consumption, JSON, XML, Images, whatever really. But I want to get back to your other statement about things taking longer. They honestly do not, I wasn't kidding when I said that an MVC app and a Webforms app is going to take the same amount of time once you get over the learning curve. The problem is the curve can be killer. It involves not only picking up good practices in MVC, but also learning javascript well, and getting back into html. You also should become familiar with a javascript framework to expidite javascript coding.

Once I had my user administration, ext grid, and error handling in place things were a breese. We didn't include the error handling in TheBeerHouse but I will post the code up tonight on this thread.

As for the codeoff, I was thinking a simple chat program would be easy enough to do. Use membership provider to log in, and basically one table to manage chat. It should be fast but at the same time also a complex UI. Let me know if that interests you. BTW I noticed that there are no open source chat room programs on codeplex, might make a nice dual post.

Aug 18, 2009 at 7:23 PM

Forgot I wrote a blog article on error handling in MVC Framework. Go here to learn how to set up error handling in mvc.