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.
