views:

132

answers:

6

After countless hours researching (creating a few demo projects, viewing webinars etc..) I feel like MVC .net works great for 90% of the web application types out there, but not for mine.

Basically I have a dashboard application where I'm displaying large amounts of information in many different graphs / charts (all on the same screen). If I change the state of a control on the page, say a date range, I would like all of the graphs / charts to update accordingly.

This is fairly trivial in webforms using usercontrols with ajax update panels, but I've not seen a 'good' simple implementation in MVC without doing most of the heavy lifting in JQuery / Javascript code.

Most of the examples of post backs in MVC involve a form submission (we don't have any forms on our dashboard) or it involves navigation from view to view (which I don't want to do either). The closest thing I can relate what we need to would be an MVVM framework but we won't be moving to Silverlight for a few months.

Am I thinking of MVC wrong, am I missing such a simple example that the major bloggers / tutorials don't cover it? Any thoughts?

A: 

If your chart/graph controls are classic ASP.net controls then it might be best to stick with a classic ASP.net application. Some of the ASP.net controls don't work too well with MVC.

Dismissile
A: 

MVC is supposed to ease your development. If it doesn't, dont use it by force. Stick to WebForms if they fit your requirements better.

Xorty
A: 

The dashboard app as you describe it doesn't sound like ASP.NET MVC would be a BAD choice.

Charts - you can use the Microsoft Charting controls with ASP.NET MVC - here's how.

Forms & Views - I can imagine you'd wrap those datepickers in form tags. Each grid or chart would have a collection or member variable of some kind on the ViewModel. Create a partial view for each grid, send the appropriate data to it as the ViewModel, and simply foreach to build a table or ul to display your tabular data as you see fit.

p.campbell
+1  A: 

No, you're not wrong. In many ways, MVC is closer to the "metal." Web Forms makes things like this "trivial" in terms of code, but usually only by making it extremely inefficient in terms of bandwidth.

MVC takes a different approach; they force you to notice inefficient practices by doing it manually. jQuery and AJAX must be added to MVC for this kind of complexity.

It does really sound like you need a Silverlight solution.

Stephen Cleary
Web Forms doesn't necessarily have to be inefficient in terms of bandwidth. That really depends on View State which can be affected by a number of decisions. It is possible to write Webforms so you minimize View State usage (although, it is an essential part of Webforms, obviously).
JasCav
@Jason: You are correct. What I meant to say was that Web Forms makes it *easier* to write inefficient code, while MVC does not.
Stephen Cleary
@Stephen - I figured that's what you meant, but I just wanted to clarify in case someone else came in looking for information. Thanks for the response.
JasCav
A: 

As others have said, MVC is not necessarily better than WebForms, and you should use what is best for your project needs. Don't use MVC just because it is the latest and greatest.

With that said, because ASP.NET MVC and Webforms use the same runtime environment, you could create an ASP.NET MVC project and use Webforms within that project when needed. That way, you can get advantage of both worlds.

JasCav
A: 

Thanks for everyone's response! I greatly appreciate it.

I found a way to make MVC work very effectively over the weekend for my use case by incorporating AJAX postbacks to particular div tags. I added a few AJAX extension methods to handle buttons / drop downs etc (also with a little JQuery) so that they call a particular controller and return a view updated in only specified divs.

Probably the basics of MVC, but once I put on my javascript hat (and stopped looking at this from a webforms perspective) it actually made a lot of sense. Also incorporating McvContrib and Ninject into my code base eased quite a few pains that I foresaw. I would highly recommend anyone looking into MVC to check out those two tools (even though Ninject isn't exclusively MVC).

Thanks again.

D^t

jasonhooten