This is an interesting discussion, and shows to me the odd state that web applications are in right now. In my mind, there are (at least) two different kinds of web applications with associated patterns.
The traditional type of HTML application, where the primary logic engine is the server. The view is a simple HTML page that acts as the view, with some javascript to do things like input validation, making things pretty, etc. The JS might even post back a certain section of the HTML view (via Ajax, JSON) to allow for updates without a screen refresh. In my mind, this is still just making things pretty. The data could be loaded via server side HTML injection/creation or JSON requests, but the key point is that the view is still a fairly dumb container. This type of applications is what ASP.NET MVC is made for, and I believe that it does a bang up job at it. None of the MS samples that I have seen show ASP.NET MVC doing anything complex on the client side. The other type of web application is (for lack of a better term) a Web 2.0 application. The actual HTML page is simply a container for a large amount of javascript that contains a bunch of logic for working with data. The data eventually gets sent back to the server (maybe. with HTML 5 even this might change) but the server is no longer the driver of things. I've written a few of these applications, and the MVC pattern starts to fall apart for me, especially ASP.NET MVC. It feels like more of a MVP or MVVM pattern - like an ASP.NET application but with the logic in the client as opposed to the server. I think it is a mistake to view all web applications as the same, using the same patterns. We now have a full featured language/runtime in the browser, but we don't need to make use of it. You can do just about anything using JavaScript - this means that all the patterns that work in a traditional app now work for a web app. Erick On Mon, Jan 24, 2011 at 4:51 AM, Chris Bilson <[email protected]> wrote: > I think the gist of it is just because it's in running in the browser > doesn't make it "view." You can have controllers and models in the browser > too. With the advent of jquery, other frameworks, and javascript unit > testing frameworks, it's a lot easier and more powerful to move this stuff > into the browser. > Another thing to consider is WCF and the OWIN stuff that Ryan, Glenn, and a > bunch of other people are doing. I think that gets you the rest of the way > to not having any empty view/controller notions on the server anymore, if > that's what your app calls for. The server part of the application is then > really just services. > > --c > > > On Sat, Jan 22, 2011 at 21:21, 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 ASP.NET/"Web" MVC seems to require two >> layers of MVC. Honestly, though, I don't know that the 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 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 ASP.NET MVC to be more difficult than 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]> >> 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: >>> >>> Load web view which declares all javascript and CSS dependencies that it >>> intends to show. >>> Once the page loads I call the REST-like web services on the server to >>> get the data I want to show >>> 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]> >>> 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]> >>>> wrote: >>>> >>>> >> -----Original Message----- >>>> >> From: [email protected] >>>> >> [mailto:[email protected]] On Behalf Of Paul McCallick >>>> >> Sent: Saturday, January 22, 2011 2:27 PM >>>> >> To: [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]. >>>> > 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]. >>>> 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. >> >> -- >> 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]. >> 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. > -- 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.
