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]<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]<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]<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]<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]<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]<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]<altnetseattle%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/altnetseattle?hl=en. > > -- ******************************** *Michael Ibarra* [email protected] @bm2yogi <http://twitter.com/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.
