It's still 1000% better than an UpdatePanel. On Sun, Jan 23, 2011 at 3:23 PM, Chris Tavares <[email protected]> wrote: > What is a service, really, but a UI that’s designed to be consumed by a > machine instead of a human? So a View that’s a service interface is, to me, > still a View as far as the pattern is concerned. > > > > I often call WCF a presentation technology and confuse the heck out of > people. J > > > > -Chris > > > > From: [email protected] [mailto:[email protected]] > On Behalf Of Adron Hall > Sent: Sunday, January 23, 2011 2:16 PM > To: [email protected] > Subject: Re: The reality of web mvc > > > > I've had a few conversations about how ASP.NET MVC is kind of not really > putting the MVC where it needs to be. It is rooted in exactly what is > written about on this thread. The real part of the whole application stack > is the client material in the browser - where almost none of the actual > "MVC" in the "ASP.NET MVC" is at. Sure the view is, but when it is > delivered to the client it really isn't the "view" so to speak, but instead > a completely seperate application. Especially when there is heavy > Javascript that creates an intensive and usable UX/UI. > > > > The thing I've found many people actually doing with ASP.NET MVC lately is > using it to provide services to a UI that is an application unto itself > using the whole JS, AJAX, CSS, HTML + whatever is web related to communicate > with those services the MVC is rendering. Sometimes of course the MVC is > providing a view that happens to provide some HTML, but otherwise even then, > it's really just services. > > > > Almost like ASP.NET MVC has been relegated to something like Model Service > Controller (MSC) instead of Model View Controller (MVC). > > > > I'm kind of reiterating what was written in previous e-mails, but would add > that MVC really is becoming a misnomer with the newer architectures that are > being put in place - even more so with the pending arrival of the HTML 5 + > CSS 3 + Javascript combination. It's really going to spin ASP.NET MVC on > its head. Where do we go then? Does Microsoft leave it called ASP.NET MVC? > Probably so, but seems like the usage of said framework is really morphing > into something else. > > > > ...and to bring up the commonly discussed other stack - Ruby on Rails. I > meet a few people every once in a while, and almost every time I discuss > with them the architectures they're working with, Ruby on Rails is being > used more and more the same way. RoR churns up some services, Javascript is > on the client doing all the heavy UI lifting. > > > > ...last totally random thought, how does the Node.js and other server side > Javascript / Full server to client Javascript effort/movement unfold in this > way? Is that idea kind of wrecking the whole MVC from the server idea? > What's the architecture then? What is the stack called then? > > > > Anyway, I'm sort of rambling, but just throwing some additional thoughts out > there around the whole ASP.NET MVC isn't really MVC - because it is starting > to be used entirely different these days. > > > > -Adron > > > > > > > > > > On Sun, Jan 23, 2011 at 1:24 AM, Michael Ibarra <[email protected]> wrote: > > I think I used the wrong words (again). Sorry. By client-side validation, I > meant input validation. I can't think of any good reason to put business > rule validation in the client. > > > > That being said, I fully agree with the previous comments that ASP.NET MVC > and the "real" MVC pattern are pretty different. I personally think > Microsoft was just capitalizing on the popularity of the real MVC pattern at > the time, much in the same way Netscape capitalized on the popularity of > Java when they renamed Livescript to Javascript when neither had anything to > do with Java. > > > > One tendency I've noticed (due in part to bad examples on MS' documentation > part) is to cram the controller methods with all kinds of logic, kind of > like people used to do with PageLoad() in the web forms code-behinds. > > > > I'm working on a side project right now using MVC2. The views are written to > be very dumb. They contain just the markup and the place holders for the > properties on the view model. The view models are dumb too. They contain the > data needed for display by the view and no methods. The controller methods > are extremely lightweight and their logic is limited to making calls to > services for reads or writes. Between the services and the controllers is a > layer that translates the domain objects from the services to the > corresponding view models and vice-versa. > > > > So far this is working pretty well. > > Hope this helps. > > > > On Sat, Jan 22, 2011 at 9:55 PM, Frank Schwieterman <[email protected]> > wrote: > > I really like JasmineBDD for unit testing my javascript :) > (https://github.com/pivotal/jasmine). > > I also use client-side inversion of control container for javascript > heavy pages (http://github.com/fschwiet/jsfioc). This is an IoC > container I've written, its being used for a fairly large project > going into production this next week. It is unfortunately not well > documented :) > Each region of the page may be associated with a component > registered with the ioc container. > As the page loads, configuration information is also included in > script blocks. These script blocks will pass the configuration > information via the ioc container. This configuration element tells > the javascript code what DOM element it should attach to, and include > any other configuration or user data. > > After page load, client calls can pass parameter to MVC controller > methods using the JsonValueProviderFactory. JsonValueProviderFactory > is in the MVC futures project for MVC 2.0, but I thought I read its > builtin to the core for MVC 3.0. > For unit testing client-side that makes AJAX calls, jasmine-ajax is > great (https://github.com/pivotal/jasmine-ajax) > > Generally the AJAX calls I make return JSON data which are turned to > HTML via jQuery templates, rather than have ASP.NET render the HTML. > I can use the same templates from my unit tests. > > On Sat, Jan 22, 2011 at 9:37 PM, Tim Erickson <[email protected]> wrote: >> As for how people are doing it, I've been toying with the idea of Script#. >> 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 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. > > -- > ******************************** > Michael Ibarra > [email protected] > > @bm2yogi > http://dev.bm2yogi.com > > > > -- > > 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. > > > -- > Adron B Hall > > Tech: http://compositecode.com > Transit: http://transitsleuth.com > Twitter: http://www.twitter.com/adronbh > > -- > 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.
