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] <mailto: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] <mailto: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] <mailto: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] <mailto: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] <mailto: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] <mailto: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] <mailto:altnetseattle%[email protected]> . For more options, visit this group at http://groups.google.com/group/altnetseattle?hl=en. -- ******************************** Michael Ibarra <mailto:[email protected]> [email protected] <http://twitter.com/bm2yogi> @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] <mailto:altnetseattle%[email protected]> . For more options, visit this group at http://groups.google.com/group/altnetseattle?hl=en. -- Adron B Hall Tech: <http://compositecode.com> http://compositecode.com Transit: <http://transitsleuth.com> http://transitsleuth.com Twitter: <http://www.twitter.com/adronbh> 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.
