As for how people are doing it, I've been toying with the idea of Script#<http://projects.nikhilk.net/ScriptSharp>. I've played with it for a personal project and I found it rather promising, even without having fully explored the ASP.NET MVC workflow integration possiibilites, which I believe may be significant. My understanding is that it was used by Microsoft for the bulk of the client coding for the Office Live web suite.
But I have yet to pull that trigger... On Sat, Jan 22, 2011 at 9:33 PM, Tim Erickson <[email protected]> wrote: > Agreed. In the context of ASP.NET MVC, a "Model" is much more like a > ViewModel from M-V-VM (a la WPF/Silverlight). A "View" is rather like > source code from which the client browser compiles an MVC engine which > renders a single View - the page. > > The ASP.MVC "Controller" is a tricky one, because you'd think Controller > implies (business) logic, but IIRC in historical MVC per se, the Controller > merely routes requests and responses aka Actions initiated from the View and > Views appropriate to the Model's response to that Action, be it a new state > or message or whatever. > > > On Sat, Jan 22, 2011 at 9:21 PM, Paul McCallick <[email protected]>wrote: > >> I don't mean that heavy JavaScript on the client is bad, just that calling >> what is going on mvc isn't totally accurate. Web apps these days demand some >> pretty sophisticated client code. I wanted to see how people are dealing >> with this. These are really good answers. >> >> >> >> On Jan 22, 2011, at 8:23 PM, Tim Erickson <[email protected]> wrote: >> >> I agree there is a sense in which <http://ASP.NET/>ASP.NET/"Web" MVC >> seems to require two layers of MVC. Honestly, though, I don't know that the >> <http://ASP.NET>ASP.NET "MVC" is as truly "MVC" as it's name implies. I >> think this is actually what has been bothering me a bit lately in thinking >> it through. If I do it the way I feel best about, the "View" of >> <http://ASP.NET>ASP.NET MVC is not so much a view at all, but rather the >> "Model" of the "Client MVC" layer. >> >> Justin's model sounds much like what I've designed for my current project, >> but in my case the "page" comes loaded with data, but NOT RENDERED. In >> other words, it sounds like I'm doing exactly what Justin is saying, but the >> controller executes the initial data request, passes it to the View in it's >> DataContext, and the "View" is "Rendered" on the server side only in the >> sense of populating the initial data in JSON assignments to JS variables >> using an Html.DataFor(x => x.DataSetProperty, "dataSetVariableName") Html >> extension that I wrote. >> >> The page loads on the client with data loaded but not rendered, and so is >> immediately available for template rendering into a Client View (HTML >> documen) by the javascript delivered in the Web View (HTML + CSS + js >> templates + js). >> >> I only do this to avoid the latency effect I've seen on some pages where >> the page loads and then it takes a second or so for any data to be displayed >> (while the data request is made after initial page load). >> >> As to Paul's original comment, I don't feel these are so much js backflips >> as they are heavier js requirements to perform the actual rendering of the >> View that was delivered by the Web MVC. It means I'm boning up on my >> javascript skills (including ways to do OO-js) and thanking the most revered >> Resig for bestowing on us mere js mortals his immortal blessing of jQuery. >> >> So I guess I do find <http://ASP.NET>ASP.NET MVC to be more difficult >> than <http://ASP.NET>ASP.NET WebForms, but only insofar as javascript and >> its syntax, constructs, patterns and editors are less familiar and >> comfortable to me than those for the C# used in WebForms code-behind. >> >> The payoff is that I absolutely feel emancipated from WebForms' tyrannical >> page lifecycle and it's incestuous commingling of concerns in code-behind. >> >> Javascript is an excellently powerful plethora of languages (there is no >> *one* javascript across browsers), and jQuery and jQuery.tmpl templating >> with JSON provide all the tools I require to be very happy writing some >> pretty clean Client MVC. Of course I'm still developing those patterns, but >> I'm only happier for it. >> >> Tim >> >> On Sat, Jan 22, 2011 at 7:32 PM, Justin Bozonier <<[email protected]> >> [email protected]> wrote: >> >>> I'm more with Ryan as well. >>> >>> In my latest project, I've split my REST-like web services from my >>> services that just show my views. My web views don't come preloaded with any >>> data. They only contain an extremely limited html mark up and they import >>> all of the javascript and css files I need to be functional. I guess you >>> could almost view them as a javascript interpretation of an IoC container. >>> My web views are then populated using a javascript templating language with >>> the data being pulled from my REST-like web service via jQuery. >>> >>> Doing things this way means that my pages are actually loaded in three >>> distinct phases: >>> >>> 1. Load web view which declares all javascript and CSS dependencies >>> that it intends to show. >>> 2. Once the page loads I call the REST-like web services on the >>> server to get the data I want to show >>> 3. Once the data gets to my client my templating framework pulls the >>> appropriate template file from my server and renders it with the data. >>> >>> It's a little chatty but I figure I can use caching where necessary and >>> right now I have no traffic. The flexibility and modularity of this approach >>> has been key for this approach. I needed to work out a way to create a bunch >>> of web views where the user experience isn't baked and where I could mix and >>> match the different views of my data at will. This is also SUPER testable. I >>> can test my REST web services using ruby's unit testing with Rack/Sinatra >>> (which is most of the complication of projects like this). >>> >>> The template logic is testable in w/e javascript unit testing framework >>> I'm using... (I'm not testing them... but I've been experimenting with TDD >>> and how far to push not TDD-ing)... and the actual web views... quite >>> honestly I just test them manually because they have never caused any pain >>> by being untested. >>> >>> I'm just getting ready to fit the site into a pre-made web design >>> template and I have no concerns that what I've done will be the least bit >>> difficult to fit into any given mould. >>> >>> On Sat, Jan 22, 2011 at 7:10 PM, Paul McCallick < <[email protected]> >>> [email protected]> wrote: >>> >>>> That's an interesting take on it, Ryan. You almost have to builld two >>>> layers of mvc - one on the client which is traditional ui style mvc, >>>> and one on the server side which is web style mvc. >>>> >>>> Mike, in old school mvc the view has no real logic in it and doing >>>> validations at that layer would be considered very bad form. In fact, >>>> the view never does anything on its own. It tells the controller what >>>> the user did, and if there is a resulting update to be made in the >>>> view, the controller will tell the view to do it. In the web world >>>> this would result in lots of round trips. >>>> >>>> >>>> >>>> On Jan 22, 2011, at 5:03 PM, Ryan Riley < <[email protected]> >>>> [email protected]> wrote: >>>> >>>> >> -----Original Message----- >>>> >> From: <[email protected]>[email protected] >>>> >> [mailto: <[email protected]> >>>> [email protected]] On Behalf Of Paul McCallick >>>> >> Sent: Saturday, January 22, 2011 2:27 PM >>>> >> To: <[email protected]>[email protected] >>>> >> Subject: The reality of web mvc >>>> >> >>>> >> I've been thinking about how most web apps these days do some serious >>>> >> JavaScript backflips, and how that sort of violates the mvc pattern. >>>> >> With all of that magic happening at the view layer, you're sort of >>>> >> forced to make some processing decisions that never hit the contr >>>> >> >>>> >> Thoughts, strategies?l >>>> > >>>> > The problem stems from the fact that MVC is a UI pattern, and web apps >>>> are >>>> > services delivering messages, not UI. A true MVC platform would be all >>>> > JavaScript. MVC just so happens to very closely match the >>>> resource-oriented >>>> > nature of the web so that it makes it difficult to catch the slight >>>> > mismatch. >>>> > >>>> > So what you really need to do is segregate your service (web app) from >>>> your >>>> > UI (JavaScript). Then you'll see the clean divisions and be able to do >>>> some >>>> > MVC with JavaScript. Check out Sammy.js, among others. >>>> > >>>> > Ryan >>>> > >>>> > -- >>>> > You received this message because you are subscribed to the Google >>>> Groups "Seattle area Alt.Net" group. >>>> > To post to this group, send email to <[email protected]> >>>> [email protected]. >>>> > To unsubscribe from this group, send email to >>>> <altnetseattle%[email protected]> >>>> [email protected]. >>>> > For more options, visit this group at >>>> <http://groups.google.com/group/altnetseattle?hl=en> >>>> http://groups.google.com/group/altnetseattle?hl=en. >>>> > >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Seattle area Alt.Net" group. >>>> To post to this group, send email to <[email protected]> >>>> [email protected]. >>>> To unsubscribe from this group, send email to >>>> <altnetseattle%[email protected]> >>>> [email protected]. >>>> For more options, visit this group at >>>> <http://groups.google.com/group/altnetseattle?hl=en> >>>> http://groups.google.com/group/altnetseattle?hl=en. >>>> >>>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Seattle area Alt.Net" group. >>> To post to this group, send email to <[email protected]> >>> [email protected]. >>> To unsubscribe from this group, send email to >>> <altnetseattle%[email protected]> >>> [email protected]. >>> For more options, visit this group at >>> <http://groups.google.com/group/altnetseattle?hl=en> >>> http://groups.google.com/group/altnetseattle?hl=en. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Seattle area Alt.Net" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/altnetseattle?hl=en. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Seattle area Alt.Net" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]<altnetseattle%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/altnetseattle?hl=en. >> > > -- You received this message because you are subscribed to the Google Groups "Seattle area Alt.Net" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/altnetseattle?hl=en.
