tag:blogger.com,1999:blog-3935408941309505852024-03-12T02:13:21.766-07:00Never In DoubtOften wrong but never in doubt ... an opinionated romp in the swampWard Bellhttp://www.blogger.com/profile/10977457957771020146noreply@blogger.comBlogger120125tag:blogger.com,1999:blog-393540894130950585.post-90304170847509241932014-02-08T12:54:00.001-08:002014-02-08T13:00:21.492-08:00Adventures in Angular Directives<p>If you’re reading this you probably know that “directives” are the Angular glue that binds the browser DOM to your JavaScript. Familiar examples include “ngModel”, “ngBind”, and “ngRepeat”. </p> <p>Angular ships with a lot of glue but the team can’t cover every possible scenario and they don’t want to try. They expect us, the authors of Angular apps, to extend Angular with our own custom directives.</p> <p>There’s a lot of great online material about directives – how they work and how to write them. People obsess so much about them that you’d be forgiven for thinking that Angular is all about writing your own directives. </p> <p><strong>Please don’t think that!</strong> You can go miles and miles without ever writing a single directive. There’s an excellent chance someone has already written the directive you need; search the web first.</p> <p><em>Angular is simple and easy to use. We seem to be doing our best to make it look difficult by glomming on to its most complex feature. Really people … let’s not scare newcomers away.</em></p> <p>I’ve been living this advice for a long time. I think I’m pretty decent with Angular and I’ve managed to avoid writing custom directives for the most part. Those that I did write were dead simple and not worth crowing about.</p> <p>I finally stumbled into the need to go beyond rudimentary directive construction with <a title="Breeze Validation Directive" href="http://www.breezejs.com/breeze-labs/breezedirectivesvalidationjs" target="_blank">the Breeze “zValidation” directive</a>. This directive taps into an entity’s validation errors collection and, if there are validation errors, will display them on screen in a red box next to the errant property. If the property is required it also displays a required indicator.</p> <p>Folks like it but they want richer display options. For example, they’d like the directive to display a label for the property in a well-defined location and change the label’s styling when the property is required.</p> <p>You couldn’t do that with my first version of this directive (which was already the hardest directive I’d ever attempted). I felt it was time to use the dreaded Angular <strong>transclusion</strong>.</p> <p><em>Hard to believe that <a title="Transclusion" href="http://en.wikipedia.org/wiki/Transclusion" target="_blank">transclusion is a real word</a> but it is … at least it is in our strange technology world</em>. <em>Ted Nelson coined it in 1963.</em></p> <p>Unfortunately, transclusion didn’t work the way I expected. I described my issue on Google Groups under the title “<a title="Can't Transclude an Input Element" href="https://groups.google.com/forum/#!topic/angular/wPkdNKW9flQ" target="_blank">Can't Transclude an Input Element</a>”. This lead to a series of helpful exchanges with the Angular community that <strong>resulted in </strong><a title="Plunker: Can't Transclude an Input Element" href="http://plnkr.co/edit/R2O2ixWA1QJUsVcUHl0N" target="_blank"><strong>a plunker code sample</strong></a><strong> </strong> <strong>that describes a path to a solution</strong>. I’ll soon rewrite “zValidate” to take advantage of what I learned.</p> <p>Meanwhile, I offer my lessons learned by reproducing below the plunker’s <strong>readme.md</strong> file that provides the details of the journey and its resolution.</p> <hr> <h1>You Can't Transclude an Input Element</h1> <p>An attribute directive that will transclude a <div> <strong>won't transclude an <input> element</strong> as seen in <a href="http://plnkr.co/edit/ov4lqLo9ZOMeDQNPfhfE" target="_blank">my original plunker</a>. <p>I can transclude a <div> or <span> that <strong>contains</strong> an <input> but not the bare <input> itself. <h3>Explanation</h3> <p>I learned from the community that I was mistaken about how transclusion works. Transclusion copies the contents of the container element, <em>not the element itself</em>. <p>My mental model had been that of <code>ngRepeat</code> in which the element that carries that attribute is included in the repeated (and transcluded) material. <p>That isn't how it works when we apply transclusion in our own directives. For us the element carrying the directive attribute is<em>excluded</em>. <h3>Solutions</h3> <p>A series of plunkers from the community made all of this clear. Alternative approaches involved a transclusion function; see <a href="http://plnkr.co/edit/9nIjKYidINVxgpIvHUPE">this one from Umi</a> and <a href="http://plnkr.co/edit/vbY33x2lcjotNxUXSrxZ" target="_blank">this one from Sander</a>. <p>Even these were overkill <em>for this particular example</em> because we weren't asking Angular to do anything with the material in the template. Under such hothouse circumstances, there is no need for transclusion either ... just some simple template manipulation as seen in <a href="http://plnkr.co/edit/wp1J7hz2tFjKkJB48I7X" target="_blank">this plunker from me</a>. <p>However, my goal isn't really that simple. My goal is to enable wrapping an input control in more complex HTML that can display validation error messages, required indicators, and labels. In all such decorations we would ask Angular to fill-in-the-blanks withdata bound to the scope. <h3>The "ultimate solution"?</h3> <p>Ok ... nothing is ever final. But this one demonstrates the essential mechanics for what I want to do. <p>It employs a <strong>compile</strong> phase to compose the template around the target element. This happens <em>before there is a scope</em> so it can't do any data binding. The advantage of performing this work in the <em>compile</em> phase before binding data values is that we <em>only perform it once</em> within an <code>ng-repeat</code> block, a fact demonstrated in the this example in the last textbox. Getting these template manipulations out of the way early might improve performance when displaying a long list. <p>The <em>compile</em> function returns a <em>link</em> function which Angular calls for each data bound scope. This is when Angular fills-in-the-blanks with actual values for each scope instance as illustrated in the textbox within the <code>ngRepeat</code>. <p>You can manipulate the output HTML in the link phase as well, as seen here: <p><code>element.find('mark').text(linkCounter)</code> <p>where the contents of a <code><mark></code> tag is filled by the local value of the <code>linkCounter</code>. <p>This example directive also demonstrates the utility (and occasional necessity) of a <strong>local child scope</strong>, enabled by the<code>scope: true</code> setting. <p>Without that setting, the <code>counter</code> would become a property of the <em>outer scope</em>. We want this <code>counter</code> <em>to update for each binding</em>. If it were not a child scope the link function would increment the one-and-only counter property and we'd see <em>that same value in all of the bindings</em>. Perhaps as bad, we risk overwriting a property of the outer scope called "counter" that we had no business touching. Comment out the <code>scope</code> setting to see what I mean. <p>Note that we must use the <em>child scope</em>, not the <em>isolate scope</em>. The templated element will surely bind to a value in the outer scope (e.g., the textbox value); an "isolate scope" would shield that value, resulting in an empty binding. Replace the scope setting with <code>scope: {}</code> to see what I mean. <h3>Todo</h3> <p>Of course this isn't the "ultimate solution". I wouldn't bake the template into the directive. I'd want it to be configurable perhaps with a template function option. I'd probably want the developer to be able to set a default template during the Angular "config" phase. <p>These thoughts are "out of scope" (yuck yuck) for the issued addressed in this example.</p> Ward Bellhttp://www.blogger.com/profile/10977457957771020146noreply@blogger.com1tag:blogger.com,1999:blog-393540894130950585.post-60217043742029949132014-01-08T02:09:00.001-08:002014-01-28T17:39:21.713-08:00Song of MyselfWith sincere apologies to <a href="http://www.poetryfoundation.org/poem/174745" target="_blank" title="Song of Myself by Walt Whitman">Walt Whitman</a>, I commend to you <a href="http://wildermuth.com/hwpod/6_Ward_Bell" target="_blank"><strong>an autobiographical sketch</strong></a> recorded with <strong>Shawn Wildermuth </strong>in late December 2013 as part of his <a href="http://wildermuth.com/hwpod" target="_blank" title="Shawn Wildermuth's "Hello World" podcasts"><strong>“Hello World” series</strong></a> of developer interviews.<br />
It covers my early years as a <strong>Knucklehead Programmer </strong>which was kind of like <a href="http://www.youtube.com/watch?v=iszwuX1AK6A" target="_blank">Wolf of Wall Street</a> minus the money, blow, and hookers. <br />
Shawn and I do have a darned good time talking about programming in the 70s/80s (APL, big iron, life before PCs and RDMS), people who changed our lives, and what we can do to nurture the developer community. <br />
Go subscribe to Shawn’s series so you can listen to a great cast of developer characters talk about how they got started in this game.<br />
I wonder if Shawn will interview himself :-)<br />
<h1>
Extra links</h1>
Shawn included a few links on his page but I thought you might like a few more with my memories attached.<br />
<h3>
Steve Dunwell</h3>
<strong>Steve Dunwell,</strong> the IBM Fellow, lead architect and manager on the pioneering <a href="http://www.dvorak.org/blog/whatever-happened-to-the-ibm-stretch-computer" target="_blank">STRETCH computer</a> is remembered in this article, “<a href="http://www.computerhistory.org/collections/catalog/102636422" target="_blank">Return of the prodigal son: the rehabilitation of Steve Dunwell</a>”. His passion for educational computing made my introduction to computing possible at a time when “computers in the schools” was almost inconceivable. <h3>
APL – A Programming Language</h3>
<a href="http://en.wikipedia.org/wiki/APL_(programming_language)" target="_blank"><strong>APL</strong></a>, my first programming language and my source of income for two decades. Here is <a href="http://en.wikipedia.org/wiki/Conway%27s_Game_of_Life" target="_blank" title="Conway’s Game of Life">Conway’s Game of Life</a> in a single line of “<em>write once, read never</em>” APL: <img src="http://catpad.net/michael/APLLife.gif" /> Look Ma! No Loops! <br />
We loved it. We owned our own 16Kb slice of an IBM/360. No overseers. No types, No compiler. Cult language. We rocked.<br />
My first “computer” was actually an IBM/360 connected by a private telephone line and acoustic coupler to this 2741 terminal, a modified Selectric typewriter. <br /><a href="http://www.computerhistory.org/atchm/wp-content/uploads/2012/10/terminal.jpg"><img alt="clip_image001" border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhnVQjp5BVJLuD3kmJJsGWyO6SCYXM-jNsTrHG4vH_YMBuzI9KOgPVnMiSoaBfP2IZHvcwv6jGvzY_JR9_lXh1JAxQDp-fGMVVQHeEGc7OghXm98SYf1vnc9c8Op8H1kUIfMFx95LYEtPp1/?imgmax=800" height="149" style="border-width: 0px; display: inline;" title="clip_image001" width="244" /></a> The Selectric Typewriter printed with a typesphere that rotated and tilted for each letter before striking a ribbon and the paper behind it (<a href="https://archive.org/details/dmbb20107" target="_blank">see video</a>). IBM made a special typesphere to print those weird APL characters: <a href="http://www.computerhistory.org/atchm/wp-content/uploads/2012/10/golfball.jpg"><img alt="clip_image002" border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjJ8X72-ZAYGHnzwX7jmo33Aa8qNgSwajn8uJ33y0L8sQ1F0ma48wVKdC0ec6nwOqU44LZl7TsOBOAFYi8pBk6MxOpmo7Z7VGHl8_3D8ED8EY-KqWMOqjm-EkKlR0hQlN0R4vUytBmxtw9h/?imgmax=800" height="185" style="border-width: 0px; display: inline;" title="clip_image002" width="244" /></a> My first green screen terminal was a 3270 display. It was roughly the size of a foot locker and must have weighed more than 50 pounds. The manual was over 100 pages. The character set was IBM’s own EBCDIC; ASCII was an option but I don’t remember seeing ASCII actually installed. A bigger, heavier color version arrived with the 3279 some years later: <a href="http://en.wikipedia.org/wiki/File:IBM-3279.jpg"><img alt="" src="http://upload.wikimedia.org/wikipedia/commons/thumb/a/a8/IBM-3279.jpg/220px-IBM-3279.jpg" height="245" width="220" /></a> <h3>
History of the Relational Database</h3>
I talked some about the early history of the Relational Database when it was fresh and exciting and how it had to overcome the predominate database architectures of its day (architectures we’d now categorize as “NoSQL” ). Did you know that it was invented at IBM by E.F. Codd. and that IBM suppressed it for almost a decade? Read all about it in this <a href="http://www.computerhistory.org/collections/catalog/102658166" target="_blank" title="Oral History of C.J. Date">fascinating interview with C.J. Date</a>. It’s a PDF. You’ll learn that Codd wrote an early relational database query language in APL (p.28) and that he hated SQL. <h3>
Community Memory</h3>
I talk briefly about my time at <a href="http://en.wikipedia.org/wiki/Community_Memory" target="_blank" title="Community Memory">Community Memory</a> one of the earliest experiments in social networking. <img alt="The first Community Memory terminal, at Leopold's Records, Berkeley, CA, 1973. Photo taken by and for the Community Memory Project, first published in the Resource One Newsletter, April 1974, and originally posted to the web in 1996 by Mark Szpakowski " src="http://news.bbcimg.co.uk/media/images/50883000/jpg/_50883927_50883926.jpg" height="228" width="304" /> The technology was a bunch of teletype terminals in Berkeley laundry mats and record stores, connected by phone lines (no internet). What fascinates me to this day was how CM’s vision of social change through social networking both did and did not happen. You get some sense of that from this BBC article “<a href="http://www.bbc.co.uk/news/technology-12224588" target="_blank">Hackers and hippies: The origins of social networking</a>” And that’s enough of that!<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />Ward Bellhttp://www.blogger.com/profile/10977457957771020146noreply@blogger.com1tag:blogger.com,1999:blog-393540894130950585.post-19173577969964231942014-01-03T18:32:00.001-08:002014-01-03T18:32:23.065-08:00Hooray for Durandal (nextGen)<p>Stop what you’re doing and <em>learn</em> <em>right now</em> about <a title="Durandal NextGen" href="http://www.kickstarter.com/projects/eisenbergeffect/durandal-2014/posts/703625" target="_blank"><strong>the next generation of Durandal</strong></a>. Watch the <a href="http://www.kickstarter.com/projects/eisenbergeffect/durandal-2014/posts/703625" target="_blank">video</a> (just 25 minutes) to see how intuitive and easy it is to build a nextGen Durandal application. Then push the “<strong><em><a href="https://www.kickstarter.com/projects/eisenbergeffect/durandal-2014/pledge/new?clicked_reward=false" target="_blank">Back This Project</a></em></strong>” button and help fund it.</p> <blockquote> <p><strong>Full Disclosure</strong>: <em>I have no connection with this project. I just like it a lot. And I put <strong>my money</strong> where my mouth is.</em></p></blockquote> <p>At IdeaBlade we’ve been big fans of <a href="http://durandaljs.com/" target="_blank">the Durandal presentation framework</a> for building Single Page Applications (SPAs) in HTML and JavaScript. Durandal has served us (and our clients) well for over two years and today’s Durandal deserves its place among the top SPA frameworks. There are lots of ways to learn about it, none better than John Papa’s Pluralsight course, “<a href="http://pluralsight.com/training/Courses/TableOfContents/single-page-apps-jumpstart" target="_blank">Single Page Apps JumpStart</a>”.</p> <p>Durandal’s author is Rob Eisenberg, known to many of you as the man behind the <a href="http://caliburnmicro.codeplex.com/" target="_blank">Caliburn.Micro</a>. Rob’s been at this game a long time. I think he must have built and re-built three or four of these presentation frameworks by now, learning and improving with each iteration. He’s didn’t just wake up yesterday and decide he could write a better framework than everyone else. He’s been writing better frameworks than almost everyone else.</p> <p>I took him very seriously (and got seriously excited) when he told me about the next generation of Durandal for <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/ECMAScript_6_support_in_Mozilla" target="_blank">ECMAScript 6 browsers</a> that are just around the corner. I’ve been tracking his new designs and his progress for several months. This next version of Durandal is going to be great.</p> <p>What’s so great about it? What’s distinctive about it? <a href="http://www.kickstarter.com/projects/eisenbergeffect/durandal-2014/posts/703625" target="_blank">Rob has his inventory</a> of laudable features (and its impressive). Here are some of the aspects of nextGen Durandal that I love … and that have no equal among alternative frameworks:</p> <ul> <li><strong>Convention over configuration</strong> – I hate writing and maintaining “switch board” code to connect FooViewModel to FooView and FooRoute etc. I want to say “Foo” and be done with it … until and unless I have a compelling reason to break convention.</li> <li><strong>Customizable conventions</strong> – Rob makes good choices but I’m free to define my own.</li> <li><strong>Page life-cycle</strong> – Durandal has baked in understanding of the birth and death of “pages” so I don’t have to make up my own hacks to ensure that new pages are initialized on creation and cleaned up on destruction. </li> <li><strong>Asynchrony throughout</strong> – Need to wait for the user to confirm or cancel before moving off the page? That’s easy in Durandal because asynchrony is plumbed through the page life-cycle and everywhere else. Dynamically load optional modules on-demand? Easy.</li> <li><strong>Diagnostics</strong> – With debug mode turned on the console tells me exactly what choices Durandal is making for me as they happen. I can tap into that logging pipeline with my own diagnostics.</li> <li><strong>Write less, do more</strong> – You all know what I mean. We all want to write less code. That’s the motherhood and apple pie that every framework promises. They usually deliver something else. Check out the <a title="nextGen Durandal Sample Video" href="http://vimeo.com/82601948" target="_blank">nextGen Durandal sample video</a> and tell me what other technology is that clear and concise.</li></ul> <p>Yes, there are other presentation frameworks out there and I like one or two of them as well. Why get involved with the Durandal project, even if it is great? Shouldn’t we just back “the winner”?</p> <p>I don’t think we can afford to just sit here and let any one of the frameworks dominate. That’s not good for the web. It wasn’t good when IE6 owned the browser world even if it was the best browser at the time. It won’t be good for the web if today’s favorite owns this presentation framework space either. Frankly, no one has nailed it yet. They all make me itch. It’s too early to declare a winner.</p> <p>We need to encourage real competition … by which I mean truly well done, distinctive approaches to our common application building problems. Durandal is a worthy competitor. It fosters ideas and techniques that must find their way into our application development practices. Durandal deserves your support. Go give it some love.</p> Ward Bellhttp://www.blogger.com/profile/10977457957771020146noreply@blogger.com3tag:blogger.com,1999:blog-393540894130950585.post-16063282248996103962013-03-03T13:50:00.001-08:002013-03-03T13:50:21.330-08:00Blogging from an iPad with Blogsy<p> My BFF Peggy is traveling to Morocco for two months. </p>
<div class="separator" style="clear: both; text-align: none;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhBieF6lHfzizDj8T3Jih6YgJBEYYDj4sRB27AbMj5f9dgqJXrg9Rv8b6F1ttFzxt_F4bltrvl7ReP4b6VoHl0qv43QqDkZc3qqgg5UlTDQJY9os9U-Ei03phqXpLmyI39klpzuLlfiy8BJ/s1024/Photo%252520Mar%2525203%25252C%2525202013%25252C%2525201%25253A41%252520PM.jpg" target="_blank" style=""><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhBieF6lHfzizDj8T3Jih6YgJBEYYDj4sRB27AbMj5f9dgqJXrg9Rv8b6F1ttFzxt_F4bltrvl7ReP4b6VoHl0qv43QqDkZc3qqgg5UlTDQJY9os9U-Ei03phqXpLmyI39klpzuLlfiy8BJ/s500/Photo%252520Mar%2525203%25252C%2525202013%25252C%2525201%25253A41%252520PM.jpg" id="blogsy-1362347276256.1045" class="alignnone" alt="" width="500" height="400"></a></div>
<p> She wants to blog about it. Who wouldnt?</p>
<p> She's facing some challenges. First, Her only computer ... an iPad mini. Typing a post on glass is not for me. I'm writing this post in that fashion and I won't last long. "Get a keyboard" I say. Which one? Don't know. Maybe someone can recommend one.<br>
</p>
<p>Second challenge: she has never blogged before. The process has to be simple. No messing around with HTML or CSS. </p>
<p>Third challenge. She writes. She won't be content with posts consisting of photos and captions. She is not a Facebook person. She will be reflecting on her experience ... You know ... Like with real words (see keyboard comment above). So FB is out. So is Tumblr</p>
<p>Fourth, without asking me, she picked Google's Blogger. Hey, I happen to use that for this blog. Wouldn't call it the easiest choice. </p>
<p><strong>Good news</strong>: after playing with it on my wife's iPad, I'm feeling pretty confident in asserting that, you're going to blog on Blogger from an iPad, <a href="http://blogsyapp.com" target="_blank" title="Blogsy">Blogsy</a> is the app to use. I'm writing this post with Blogsy.</p>
<h2>It formats!</h2>
<p>Of course it should. What's nice is that it was intuitive from menu bar.</p>
<h2>Picture ... or it didn't happen</h2>
<p> </p>
<div class="separator" style="clear: both; text-align: left;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEie9jQNFAClRciF7oujtWFLdULDej2ISjymdiroNLMVlBQ6-N-hKPkaqN2b4b6dlqRkTCyiSvdKko0x_iRjFjZP97Ny6_Lcv4ucarxuD10SIW5gtmSFjoAKaLF5mE3yyf3d6pvM4gqyfOPe/s1024/Photo%252520Dec%25252025%25252C%2525202012%25252C%2525209%25253A35%252520AM.jpg" target="_blank" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEie9jQNFAClRciF7oujtWFLdULDej2ISjymdiroNLMVlBQ6-N-hKPkaqN2b4b6dlqRkTCyiSvdKko0x_iRjFjZP97Ny6_Lcv4ucarxuD10SIW5gtmSFjoAKaLF5mE3yyf3d6pvM4gqyfOPe/s300/Photo%252520Dec%25252025%25252C%2525202012%25252C%2525209%25253A35%252520AM.jpg" id="blogsy-1362347276214.4966" class="alignleft" alt="" width="300" height="400"></a></div>
<p> Great features. Great integration with wide variety of resources. Easy to use (for me; I hope easy for her too) after you watch the excellent video on <a href="http://blgsyapp.com/video/dragndrop.html" target="_blank" title="">dragging and dropping</a>.</p>
<p>Here I'm inserting a picture of my dog which happens to be on this iPad. He fits right in. I can wrap text around him too.</p>
<div class="separator" style="clear: both; text-align: none;"> And then I can resume with my post after the photo. This was easy to do by dragging and tapping.</div>
<p> Enough typing on glass. If you're reading this you know I published successfully ... and that it ain't gonna be so bad blogging from Morocco on an iPad.</p><div style="text-align: right; font-size: small; clear: both;" id="blogsy_footer"><a href="http://blogsyapp.com" target="_blank"><img src="http://blogsyapp.com/images/blogsy_footer_icon.png" alt="Posted with Blogsy" style="vertical-align: middle; margin-right: 5px;" width="20" height="20" />Posted with Blogsy</a></div>Ward Bellhttp://www.blogger.com/profile/10977457957771020146noreply@blogger.com1tag:blogger.com,1999:blog-393540894130950585.post-44480917128121817802013-02-25T20:10:00.001-08:002013-02-25T20:19:12.185-08:00The Breeze Server: "Have it your way"<p><strong>BreezeJS is a 100% JavaScript client library</strong>. It can work with any backend that speaks HTTP.</p> <p>It's hard to get that message across when most Breeze samples demonstrate a Breeze client talking to a Web API controller with Entity Framework and SQL server behind it. Understandably, some people believe that Breeze only works with Web API, EF, and a SQL database. We need more samples to show alternatives. We're working on those.</p> <p>In the absence of those samples, please sing along with me now, the unforgettable "<em>Have it your way</em>" jingle from the <a href="http://www.youtube.com/watch?v=CJMsFGH4eoQ" target="_blank">1976 Burger King commercial</a>. Curse me later for your inability to get that song out of your head.</p> <p>For the hard of hearing, I'm reprinting an email I sent recently to my web developer friends on this subject.</p> <div id="scid:0767317B-992E-4b12-91E0-4F059A8CECA8:15edd71d-7c70-47c7-990f-964b614c4373" class="wlWriterEditableSmartContent" style="float: none; padding-bottom: 0px; padding-top: 0px; padding-left: 0px; margin: 0px; display: inline; padding-right: 0px">Technorati Tags: <a href="http://technorati.com/tags/BreezeJS" rel="tag">BreezeJS</a>,<a href="http://technorati.com/tags/JavaScript" rel="tag">JavaScript</a>,<a href="http://technorati.com/tags/SPA" rel="tag">SPA</a></div> <p> <hr> </p> <p>I'd like to clear up some misconceptions about <a href="http://www.breezejs.com" target="_blank">BreezeJS</a><strong></strong> regarding the relationship between data on the client and data on the server. Want the gist? Head straight to the <a href="#summary">Summary</a> at the end. </p> <p>BreezeJS is a library for building CRUD applications in client-side JavaScript and HTML. A Breeze application depends on a JavaScript entity model defined for the application domain <em><strong>as that domain is understood on the client</strong></em>. </p> <p>How closely the client entity model corresponds to a model on your server is entirely up to you. The client-side <strong>BreezeJS is happy to accommodate you</strong>!</p> <p>For many developers, the independence of the client and server models is a matter of principle and they will go to great lengths (and write a ton of server code) to demonstrate and defend that principle.</p> <p>Personally, I'd rather write less code. The hardest part of my application will be building a tolerable UI that meets the application requirements for functionality, data integrity, security, and usability. That's a tall order. I'm not eager to do more than I have to. Moreover, I would gladly postpone some heavy coding decisions today if I am confident that I can change direction tomorrow without a massive rewrite. That perspective informs my preferred Breeze development path. Your perspective may be different. </p> <p>As I said, the Breeze client entity model need not correspond to any server model. But it's a heck of a lot easier when it does. We paved a rose-petal path for the .NET developer who is happy with a Web API service talking to Entity Framework for data access and mapping to a POCO entity model. Breeze.NET components make it easy to expose EF metadata and <font face="Courier">IQueryables</font> to a Breeze client and, yes, they make it easy to open the kimono to the client. Fortunately, with just a little effort you can show a lot more discretion and remain productive.</p> <p>I am unashamed to take this path myself. I have no desire to waste valuable customer time and money moving data into and out of DTOs "on principle". I am reluctant to “pollute” the server with hundreds of controllers each with 4 or more methods. </p> <p>I am not kidding about the consequences. The typical business application has a minimum of 200 domain model types. 90+% of the time the shape of the data I'm sending over the wire is the same as the shape of the entity in my business model. An Order in the database often looks like an Order in the domain model and the Order in the domain model probably look like an Order on the client most of the time. When such an entity meets the <a href="http://json.net/" target="_blank">JSON.NET</a> serializer <strong>it might as well be a DTO</strong>. </p> <p>When the entity type is simple, it is likely to have the same shape in every layer. In my experience, models are dominated by relatively simple types and types with no serious privacy concerns. There are usually a few hairy ones that need close attention; the vast majority to not merit that much love.</p> <p>I know how to guard queries so that the right people get the right data. Of course I always inspect the change-set data coming from the client to make sure they actually should be saved before I tell my persistence machinery to save them. This essential effort is no more complicated or onerous with Breeze than any alternative you can propose.</p> <p>You are welcome to disagree. I know that <strong>some of you <em>do disagree</em></strong>. Fine. Have it your way. Replace the database with your favorite backing store. Create DTOs. Add more controllers with more fine-grained query and save methods to do exactly what you want. Don't like <font face="Courier">$expand</font> or <font face="Courier">$select</font>? Deny them! Can't figure out how to make <font face="Courier">IQueryable </font>work for your DTOS? Don't use <font face="Courier">IQueryable</font>. <strong>BreezeJS is happy to accommodate you</strong>! </p> <p>Of course you'll be writing more code on the server. You've signed up for all the mapping, the DTO files, the controllers, layers, duplicate guard logic, and the whole nine yards. In no time you'll be praising an auto-mapper that automate away the tedium that, from my perspective, you never needed to endure in the first place. You'll paper your walls with intricate architecture diagrams and reams of API documentation. Good luck training your successors. Knock yourself out. <strong>BreezeJS is happy to accommodate you</strong>! </p> <p>Realize that your server-side choices may oblige you to write more code on the client too. Most developers really like the Breeze LINQ-like style for writing <em>ad hoc</em> queries (a staple of LOB apps). Breeze translates these queries into OData URL query syntax before sending them to the service. </p> <p>An OData service knows what to do with that syntax. A Breeze Web API <font face="Courier">ActionFilter</font> can apply that syntax to your controller's <font face="Courier">IQueryable </font>methods … if they exist and to the extent that they support the range of options supported by OData query syntax. </p> <p>Don't like that syntax for your service? If your service API doesn't want to play, then your Breeze client shouldn't make those requests. The Breeze "EntityManager" can make a bare resource request to any HTTP endpoint. You can easily take on some simple data parameters if your service knows how to handle them. If you're more ambitious, you can replace the Breeze AJAX plugin (<font face="Courier">$.ajax</font> by default) or write your own <font face="Courier">dataservice</font> adapter. <strong>BreezeJS is happy to accommodate you</strong>. </p> <p>When the server responds, all that matters to BreezeJS is that the response payload contains JSON data. When Breeze sees objects that it recognizes as entity types, it turns those object into entities and caches them. But the data can also be plain old JavaScript objects. </p> <p>Yes, I frequently send non-entity data to my Breeze app too. I make liberal use of projections when I don't need entities. Sometimes I write the projections on the client; sometimes I write them on the server. When the shape of a client entity doesn't align well with the shape of a server-side business entity, I may switch to a DTO for that particular case. I won't do that if I don't have to. I know that I can do it whenever I want to. </p> <p>You'll get more Breeze benefits if the objects in the query result payload actually are entities. Breeze enriches entity objects with data binding support (Knockout, Angular, Backbone), validation, change tracking, and whatever custom properties and behaviors you've defined for objects of that type. Breeze caches entities and you can ask it to serialize part or all of a cache to local browser storage for offline and intermittent connectivity scenarios. </p> <p>How does Breeze know if the data objects are entities? It looks up their accompanying type names in its <font face="Courier">MetadataStore</font>. What's in the store? <font face="Courier">EntityType</font> definitions that describe data properties, navigation properties, validations, and custom behaviors. “Custom behaviors” are JavaScript methods you add to the metadata that describe the client-side <font face="Courier">EntityType</font>. These methods may duplicate logic you have in a server-side entity model. More often they are application logic to improve the user’s experience of the entity. </p> <p>Where did that metadata come from? Well, the easy way to get metadata on the client is to ask the server for it. Breeze accepts OData metadata. Breeze also accepts an extended form of OData metadata that you can generate with Entity Framework … another benefit of allowing the client entity model to be shaped like your EF domain model. </p> <p>But you don't have to get your metadata from the server and the metadata don't have to correspond to any particular server-side entity model. You can create the metadata entirely on the client if you wish (as we show in our "NoDb" sample). <strong>BreezeJS is happy to accommodate you</strong>.</p> <p>If you want Breeze to materialize your JSON data as entities, the metadata do have to match the "service model" exposed through your service. This service model does not have to be an entity model. It is simply the collection of "types" that you serialize to the client in response to API calls. That service model could consist entirely of DTO types … if that's how you want to roll. It's just more code, right?</p> <p>I suppose you could send any damned thing over the wire if you were willing to catch it and parse it yourself. You can create entities on the Breeze client out of data from any source … and make them appear to have been queried entities. That's how I construct test entities for my automated tests. It's just more code. <strong>BreezeJS is happy to accommodate you</strong>. </p> <p>Finally, there is the matter of saving client-side changes. The easy way is to ask Breeze to detect all pending changes (adds, mods, deletes) to all kinds of entities (e.g., orders and line-items) … bundle them up and send them to the server as a change-set. Breeze.NET helpers on the server give you ready access to the bundle so you can inspect it, reject it, modify it, map it … as your heart desires. If using the vanilla Breeze.NET EF helper, the bundle will be saved as a single transaction. </p> <p>Alternatively, you can cherry-pick the entities to save in a bundle.</p> <p>Got your own save commands, Mr. CQRS? It’s easy to pull sub-graphs from the client cache and shape your own command payload. </p> <p>Btw, you can have as many separate caches (separate “EntityManagers”) as you like, each of the isolated from the others. It’s easy to flow entities across caches (e.g., reference lists for dropdowns) so you don’t have to go back to the server all the time. I often use separate caches for different tasks, e.g., “sandbox editors”). <strong>BreezeJS is happy to accommodate you</strong>. </p> <a name="summary"></a><h1>Summary </h1> <p>My life as a developer is easier when I have the same EntityType shapes, end to end, and use Web API + Entity Framework to make it so. It can be almost as easy if the service is an OData service</p> <p>I'm not worried about so-called tight coupling of the client to the server. I'm building CRUD apps. 9 out of 10 times the reason I'm changing the server-side entity model is in response to a business requirement affecting the client. I'm going to be making changes on both sides anyway in lock-step fashion. And … as I said … I can break the symmetry any time at any point in the model without tearing down the whole house. </p> <p>But If you want DTOs everywhere, all the time, have at it. Breeze can still help you on the client with data binding support, validation, change-tracking, and caching. </p> <p><strong>BreezeJS is happy to accommodate you</strong>. </p> Ward Bellhttp://www.blogger.com/profile/10977457957771020146noreply@blogger.com6tag:blogger.com,1999:blog-393540894130950585.post-53197302612563020262012-10-17T12:02:00.001-07:002012-10-17T12:38:55.474-07:00Add the Visual Studio Command Prompt to VS2012<p>Several times this week, I wanted to launch a Windows command prompt (<em>not</em> the VS Command Window which is different) while in Visual Studio 2012. More specifically, I wanted to open the command prompt in the directory of the item I had selected in Solution Explorer. I swear I could do that in VS2010 but I can’t find that in VS2012.</p> <p>I gave up and did a two step dance:</p> <ol> <li>Right-click selected folder | “Open Folder in File Explorer” [alternatively: “Open Containing Folder”] <li>Ctrl-Shift-right-click | “Open command window here”</li></ol> <p>That works for most purposes although I don’t benefit from the VS-specific environment variables.</p> <p>Then I stumbled across an <a href="http://www.codeproject.com/Articles/24305/How-to-Add-the-Visual-Studio-Command-Prompt-VSCP-t" target="_blank">old blog post by V K Sumesh (2008)</a> that describes how to add the Visual Studio Command Prompt (VSCP) to the tools menu. That’s worth a read for background. I’ve updated the steps here for VS 2012 and to suit my preferences.</p> <h2>Add VSCP to the Tools menu</h2> <ol> <li>Tools | External Tools … <li>Click [Add] <li>Title: Command Prompt <li>Command: C:\Windows\System32\cmd.exe <li>Arguments: "%programfiles%\Microsoft Visual Studio 11.0\Common7\Tools\vsvars32.bat" <li>Initial directory: $(ItemDir) <li>Click [Move Up] to position the command (I put mine at the top)</li></ol> <p>In step #5 I’ve specified <em>vsvars32.bat</em>, a batch file that supplements the Windows environment variables with environment variables for the .NET framework tools.</p> <p>In step #6 I picked the “Item directory” because that’s my preference but the dialog offers other choices which may suit you better. </p> <p>Here’s what it looks like before I click [OK]</p> <p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEinX3IaUrdruJ1lZaFizXoQfKv4xEpdAdl-oSefPJyirp7fSYma7c5FddZDKreoeyv0S3LcBacPPmHusr9pdw5fslTKPMebJpmT5ozCBQodnIT83SIljirujE-1G9PokUtTdNCaRjkhZLRG/s1600-h/VSCP%25255B3%25255D.jpg"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="VSCP" border="0" alt="VSCP" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEilcC6GXAyiQ3k7N3Xb4w797RBQaBdlUZ1XmP6vQx25VCxV6gctU0i0ZDDchxOErlo9Ao1_en6iVBsVNuVBnUtopbMG0vTBLnfY-wh62db8S5GJ29DJc8XMeI0bgzDPyNZlZhlRMifpsDtl/?imgmax=800" width="338" height="335"></a></p> <h2>Use it</h2> <ol> <li>In Solution Explorer select the folder or item where you want the command window to open <li>Tools | Command Prompt</li></ol> <p>Hope that helps. Let me know if there’s a better way.</p> <h2>Update</h2> <p>The “Open command prompt” feature that I remembered from VS2010 came by way of the Microsoft “<a href="http://visualstudiogallery.msdn.microsoft.com/e5f41ad9-4edc-4912-bca3-91147db95b99?SRC=VSIDE" target="_blank">PowerCommands for VS 2010</a>” extension. </p> <p>Apparently the 2010 extension works for VS2012 as well. Take note: there are a ton of features in that extension, many of them already in VS2012. I was worried about redundancy and bloating my context menu with ever more rarely used options. But it seems well-behaved and you can disable features you don’t want via Tools | Options | PowerCommands. It’s a worthy alternative to the technique I described above.</p> Ward Bellhttp://www.blogger.com/profile/10977457957771020146noreply@blogger.com2tag:blogger.com,1999:blog-393540894130950585.post-70546253871559641982012-10-16T13:55:00.001-07:002012-10-16T13:55:18.595-07:00Update a NuGet package with MSBuild<p>In this post I’ll show you how to add a prebuild MSBuild target to your project that updates a NuGet package in the project when you rebuild.</p> <h1>Background</h1> <p>We ship a <a href="http://www.breezejs.com/documentation/download" target="_blank">zip file of BreezeJs samples</a> . Some (soon to be all) of them rely on a NuGet package to supply the Breeze JavaScript files and other dependencies. </p> <p>Breeze changes regularly (for the better we think) and so must the NuGet package version. </p> <p>Our sample solutions are set to <a href="http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages" target="_blank">restore all NuGet packages</a> so that we don’t have to ship them as part of the zip. Unfortunately, the “<em>packages.config</em>” file that identifies the BreezeJs NuGet package is stuck with the old version. Package restore simply grabs the old version of that package.</p> <p>We could not find a way to markup the items in the <em>packages.config</em> so that NuGet restored the latest version of the package. It always restores the exact version identified in <em>package.config</em>.</p> <p>We don’t want to modify those samples every time we update the NuGet package. We want the samples to update to the latest BreezeJs automatically.</p> <p>We don’t want to update every package in the solution; just our BreezeJs package and its dependencies.</p> <h1>Solution</h1> <p>We added a prebuild target to the bottom of the project file. The target invokes <em>nuget.exe</em> from the command line, telling it to update only our package (“<em>Breeze.MVC4WebApi</em>”) and its dependencies. </p> <p>We know that <em>nuget.exe</em> is in the project sibling “<em>.nuget</em>” directory because that’s where the package restore facility puts it.</p> <p>Here’s our target:</p><pre><Target Name="BeforeBuild"><br> <Exec Command="&quot;$(SolutionDir).nuget\NuGet&quot; update &quot;$(ProjectDir)packages.config&quot; -Id Breeze.MVC4WebApi" /><br></Target></pre> Ward Bellhttp://www.blogger.com/profile/10977457957771020146noreply@blogger.com0tag:blogger.com,1999:blog-393540894130950585.post-68159132418928767652012-10-07T11:43:00.001-07:002012-10-07T11:51:51.984-07:00Tribute to Code Camp<p>Let us sing praise to code camps everywhere and in particular to the <a href="http://www.siliconvalley-codecamp.com/">Silicon Valley Code Camp</a> here in the San Francisco bay area. I’m just home from SVCC which, at 2500 attendees, is one of the largest (if not <em>the</em> largest) code camps in the country. At any hour I could choose from twenty-five sessions touching a wide range of technology interests. </p> <p>Yet SVCC retains an intimacy and immediacy unmatched by formal conferences of equal size. Like all code camps, SVCC is free to everyone, supported by an army of volunteers and industry sponsors (thank you, sponsors!). People flock to camp to share their enthusiasms and discover something unexpected. The mood is jolly and infectious.</p> <p>It’s a wonderful place to speak. It’s a <strong>terrific opportunity to learn to speak</strong>. Never spoken publically before? Do you have the urge? Feeling a little shy? Don’t hold back … bring your talk to a Code Camp. Code camp welcomes all speakers and every speaker, novice or veteran, finds a respectful audience. Code Camp is the place to lose your stage fright and speak your mind. </p> <p>You will connect! At many conferences, the room is dark, the faces are lit by laptops, and it is painfully evident that many in your audience are twittering, emailing, or doing something other than listening. At Code Camp, the lights are up and they’re paying attention. They interrupt constantly with questions and observations. I know exactly how my talk is going, what points are resonating, which are falling flat. I go where my people want me to go. My talk becomes conversational. My nerves calm, my fear of failure dissipates … I’m having a conversation. You really must try it!</p> <p>Are all the talks good? No, of course not. You’re bound to think, “geez, I could do better than that!” Maybe you can. You won’t know until you put yourself on the line … and you owe that experience to yourself.</p> <p>Even the inept talk has much to offer. When the speaker cares … and at camp they really care … something of interest always bubbles to the surface. I imagine myself trying to tell the same story, wondering how a different image, a different phrase, a dramatic gesture might make it more compelling. I always come away with some fresh tidbits on the speaker’s subject and a page full of ideas for improving my next presentation.</p> <p>Finally, a big thank you to the organizers and volunteers at SVCC. An effective conference is no accident. It’s a lot of details and asses-and-elbows. I don’t know about you but I’m always either lost or anxious about getting lost. Driving onto the sprawling Foothill College Campus, a volunteer greets me at the gate and points the way to 4 parking lots, all free thanks to sponsors. Signs every 100 yards along the long winding road lead me confidently to these lots. I step out of the car and hundreds of signs, on the ground and on walls, always in sight, guide me to registration and from there to session rooms. There’s a map on the back of my badge.</p> <p>Lunch for 2500? No problem … lines move swiftly through the hall; in minutes I’m out on a grassy knoll (not <em>the</em> grassy knoll), under sunny skies, deep in conversation.</p> <p>For us, speakers and attendees, the day flows effortlessly; we are oblivious to the many things that are going wrong. Maybe the coffee is late. Or all the badges disappeared. The volunteer team scrambles and all is set right. The illusion of calm is sustained. </p> <p>It’s a magic act made possible by hard work, years of organizing experience, and tons of passion. I urge you to be a part of it. Attend a code camp, speak at a code camp, volunteer at a code camp. You need code camp and code camp needs you.</p> Ward Bellhttp://www.blogger.com/profile/10977457957771020146noreply@blogger.com2tag:blogger.com,1999:blog-393540894130950585.post-69678983675360334792012-09-28T00:02:00.001-07:002012-09-28T00:02:47.970-07:00The SPA as Horseless Carriage<p>Lately I’ve been talking a lot about rich client applications written in HTML and JavaScript. These are frequently referred to as “SPAs” (Single Page Applications). I call them SPAs myself – it’s cute and flows easily off the tongue. </p> <p>Unfortunately the phrase “single page application” badly misrepresents the true nature of this architectural style. <a href="http://www.infoq.com/presentations/Backbonejs">It reminds Jeremy Ashkenaz of the “horseless carriage”</a>. Both notions capture a small truth while overlooking the larger significance of the technologies involved. No one in the 21st century describes the automobile as a vehicle without a horse. Someday we won’t describe a JavaScript client application as an “app hosted in a single web page.” </p> <p>What really matters is that the client application resides and executes on the client in the same way that desktop applications do. In every important respect these <strong>are</strong> desktop apps; they just happen to be written in HTML and JavaScript.</p> <p>The single page host is a mere artifact, the app’s least interesting characteristic.What matters is the rich, responsive, productive user experience made possible by execution on the client, state on the client, and dynamic composition of the UI on the client. These apps go to the server only for resources and services that they cannot obtain locally. They communicate with the server mostly to get the latest data and to store user changes.They are otherwise self-reliant and (if designed for it) can function without a server connection for extended periods. This is what distinguishes them from the now-traditional thin client model that is the web form or MVC application – the carriage drawn by a horse.</p> <p>The carriage has become something else, a new form of locomotion. The UI has become something else, a new form of web application. The transformation is so sudden and disorienting that we cling to the thing that is lost: the horse, the web page.Eventually we will regain our balance and take for granted what seems novel today. We will find betters words to describe what this is.</p> <p> Until then, I’ll call them SPAs, however quaint that will seem in a few years time.</p> Ward Bellhttp://www.blogger.com/profile/10977457957771020146noreply@blogger.com3tag:blogger.com,1999:blog-393540894130950585.post-58567859967124324212012-08-29T23:50:00.001-07:002012-08-29T23:50:57.956-07:00Single Page App course just published on Pluralsight<p>This is a momentous event. John Papa has been working for months on a video course that covers building a JavaScript Application from end-to-end with today’s JS technologies. And he just published it.</p> <p>Get it here: <a href="http://pluralsight.com/training/Courses/TableOfContents/spa">http://pluralsight.com/training/Courses/TableOfContents/spa</a></p> <p>It’s free for the next 48 hours (free access ends on Friday, August 31, 2012 at 5pm MDT) so I’m rushing to announce it now. Honestly,even if you miss the 48 hour window, it’s worth subscribing to Pluralsight for at least a month just to watch it. Throw a little more change in the meter to get the <a href="http://pluralsight.com/training/Products/Individual">“Plus” subscription</a> so you can download the Code Camper source code.</p> <p>I’ll have much more to say about the course and the code over the coming months. I wish I could do so <strong>right now</strong> … but I’ve got a product to release. After that … I’m on it!</p> <p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh5uJWself0B6evftUmeUqtk6S1jwtpF3r4f8p-mfChNLKr2EN2PLSfW1hGTgL4beKO5IZVtgJRJ5sKTCnj4rcVFfWeZD9-8hAwmSFHkWVQCS3aWPzHGNnLm-ioUOsmGzmqdYL-IVro4Y7g/s1600-h/CodeCamper%25255B6%25255D.jpg"><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="CodeCamper" border="0" alt="CodeCamper" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiGnaTlpoyG2911bDWM2qpoFq5HZaf8sgICU0jAEKt4Y0pim1zDTySRhRs3uqBOVrj5YQos9ivi6GHVabdztp8ThcTSleqxl7vhezoo-VMptQDAEJba3y9qHNj0stI8NAAGD5L8To4-U4Ka/?imgmax=800" width="590" height="512"></a></p> Ward Bellhttp://www.blogger.com/profile/10977457957771020146noreply@blogger.com1tag:blogger.com,1999:blog-393540894130950585.post-1634886981897098012012-07-04T15:36:00.001-07:002012-07-04T15:36:40.639-07:00HTML or XAML? A chat with Jesse Liberty<p>It depends … but you knew that. Depends on what? Jesse and I approach this question from many angles on his show, “<a href="http://jesseliberty.com/2012/07/01/yet-another-podcast-69ward-bell/">Yet Another Podcast #69</a>” which aired on July 1st. </p> <p>I’ve been spending a lot of time in the world of JavaScript Single Page Apps this year … an experience that has been entertaining, thrilling, confounding … and confirms (for me anyway) that HTML/JS clients have a real <em>future</em> in LOB apps. I emphasize <em>future</em>. In the present, you’d better think twice, especially if you’ve got a big application to deliver this year and you don’t absolutely have to run it on every kind of device. If you can target windows devices exclusively (and many business apps can), you’ll be more productive and save money by building a XAML client that will last for years. </p> <p>I cover this ground and more in our 30 minute podcast.</p> Ward Bellhttp://www.blogger.com/profile/10977457957771020146noreply@blogger.com0tag:blogger.com,1999:blog-393540894130950585.post-60819329738085933572012-07-04T15:15:00.001-07:002012-07-04T15:15:44.200-07:00jsFiddle in 6 minutes<p>I produced a <a href="http://www.youtube.com/watch?v=zrWkRHSK6A8&feature=youtu.be">short video</a> introduction <a href="http://jsfiddle.net/">jsFiddle</a>, one of my favorite free tools for JavaScript developers. I published it back in May and forgot to blog about it. It still holds up (despite the regrettably harsh sound quality; turn down your volume). Check it out.</p> Ward Bellhttp://www.blogger.com/profile/10977457957771020146noreply@blogger.com1tag:blogger.com,1999:blog-393540894130950585.post-19799330317516569742012-06-18T08:58:00.001-07:002012-06-18T09:02:11.868-07:00In Answer to your Query<p>The Service Department explains Microsoft’s latest shift in strategy:</p> <div style="margin-left: 4em"> <p>We are sorry to inform you<br>the item you ordered<br>is no longer being produced.<br>It has not gone out of style<br>nor have people lost interest in it.<br>In fact, it has become<br>one of our most desired products.<br>Its popularity is still growing.<br>Orders for it come in<br>at an ever increasing rate.</p> <p>However, a top-level decision<br>has caused this product<br>to be discontinued forever.</p> <p>Instead of the item you ordered<br>we are sending you something else.<br>It is not the same thing,<br>nor is it a reasonable facsimile.<br>It is what we have in stock,<br>the very best we can offer.</p> <p>If you are not happy<br>with this substitution<br>let us know as soon as possible.</p> <p>As you can imagine<br>we already have quite an accumulation<br>of letters such as the one<br>you may or may not write.<br>To be totally fair<br>We respond to these complaints<br>as they come in.<br>Yours will be filed accordingly,<br>answered in its turn.</p></div> <p>One of <a href="http://en.wikipedia.org/wiki/Naomi_Lazard">Naomi Lazard</a>'s poems from a faceless bureaucracy in <i>Ordinances</i>, first published in <i>The Ohio Review</i> (Ardis 1984). Discovered by me in Garrison Keillor’s <em>Good Poems for Hard Times</em>.</p> Ward Bellhttp://www.blogger.com/profile/10977457957771020146noreply@blogger.com1tag:blogger.com,1999:blog-393540894130950585.post-16577115624833973512012-04-09T17:44:00.001-07:002012-04-27T12:30:01.377-07:00DevForce and Second Level Caching<p>We are asked occasionally whether DevForce supports second level caching, that is, does DevForce have some means on the server of remembering previously queried entities between client requests.</p> <p>This is rarely a real problem in a DevForce application because (a) DevForce applications are usually rich client applications and (b) the DevForce <em>EntityManager</em> cache typically delivers the performance benefits folks seek from a server side cache.</p> <p>My response, although grounded in long experience, is not always persuasive. Second level caching should improve scalability in theory and theory often trumps reality.</p> <p>In this post I discuss how to tell if you would benefit from server-side caching and how you might be able to use an Entity Framework second level cache to achieve it.</p> <p style="background-color: #f8e4b0; margin-left: 20px; margin-right: 20px">I haven't tried to install an Entity Framework second level cache. In this post I provide links to information about how to implement second level caching. The links come from reliable sources and it looks like this kind of caching should work. If you try it, please let me know how it goes. I haven’t tried it myself because I find that, for almost all of our customers, this is a solution looking for a problem. But if it makes sense for your application and you give it a try, I'm counting on you to get back to me with your results… and maybe contribute some guidance and code to help others.</p> <h2>Perceived Problem</h2> <p>You have a great many users who repeatedly query for the same entities. Those entities hardly ever change but for some reason they keep asking for them and for some reason you can’t cache them on the client. </p> <p><b>You’ve measured</b> and these queries account for a significant percentage of database hits. Moreover, they’re really bogging the database down. You’ve determined conclusively, after careful study of production traffic, that these repetitive database queries are choking your database. You’re pretty sure that server-side caching would provide significant relief.</p> <h2>Are you sure?</h2> <p>Honestly, I don’t think this happens often … which is why you should have the measurements that prove poor performance is traceable to this cause. <b>Don’t</b> <b>guess</b> that this is the problem. <b>Don’t forecast</b> that it is going to be a problem. You need proof. </p> <p>The interest in second level caches arises most often among people who are evaluating DevForce and haven’t yet built an application with it. Such inquiries are typically speculative. Trust me, you can waste a lot of time investigating something that isn’t going to make any real difference in your application. It might make matters worse.</p> <p>But suppose you’ve demonstrated that this is a real problem in your working application. You’ve established that the client app can’t cache these entities locally for some reason (perhaps it’s a web client) … which may be why you’re looking into caching on the server.</p> <p>Maybe it really is time to consider EF “<b>Second Level Caching</b>” </p> <p style="background-color: #f8e4b0; margin-left: 20px; margin-right: 20px">You could try caching query results in a <a href="http://drc.ideablade.com/xwiki/bin/view/Documentation/query-server-lifecycle-events" target="_blank">Query Interceptor</a>. But that will require code <b>you</b> must write and if an <em>EntityServer</em> (aka, BOS) is involved you’ll have to make it thread safe. Consider EF “Second Level Caching” before rolling your own.</p> <h2>If there’s a 2<sup>nd</sup>, there must be a 1st</h2> <p>Time for some definitions. The “first level cache” is the local cache of entities retrieved by some persistence manager. The DevForce <i>EntityManager</i> is a first level cache on the client. EF’s <em>ObjectContext</em> is a first level cache on the server. </p> <p style="background-color: #f8e4b0; margin-left: 20px; margin-right: 20px">When writing with EF Code First, you create a <em>DbContext</em> which is wrapper around an ObjectContext. You can think of your DbContext as a first level cache if you wish.</p> <p>On the <i>EntityServer</i> (aka, the BOS) DevForce creates a new <i>ObjectContext</i> for each client request.</p> <p style="background-color: #f8e4b0; margin-left: 20px; margin-right: 20px">This EntityServer is in-process in a 2-tier deployment.</p> <p>These first level caches do a great job of holding frequently requested entities. But they (and their entities) disappear when the <i>EntityManager</i> or <i>ObjectContext</i> disappear. The <em>EntityManager</em> on the client can live a long time, the life of the user session perhaps. The <em>ObjectContext</em>, on the other hand, evaporates after each client request.</p> <p>If you had a “second level cache” it would sit <b>outside</b> of the EF <i>ObjectContext</i>. It would outlive the <em>ObjectContext</em> and would be shared by multiple instances of <em>ObjectContexts</em>. When your query reaches a new, empty <em>ObjectContext</em>, EF makes a request to the database. A second level cache could intercept that database request and satisfy it with previously retrieved results. </p> <p>That sounds like the perfect resolution to your problem. If you had a second level cache, it could hold query results for the entities that clients are clamoring for … and the database pressure would be reduced.</p> <p>Unfortunately EF doesn’t have an out-of-the-box second level cache. </p> <p>From time to time you’ll hear someone argue that NHibernate is better than EF because NHibernate <em>does</em> have a second level cache. Often the person making this argument (a) is unaware of the limitations of a second level cache, (b) doesn’t realize that DevForce client-side caching usually eliminates the need for a second level cache and (c) has no evidence that the application would benefit from a second level cache. There’s the whiff of <a href="http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt" target="_blank">FUD</a> in the air.</p> <p>Let’s deodorize. As it happens, there is an <a href="http://blogs.msdn.com/b/adonet/archive/2010/09/13/ef-caching-with-jarek-kowalski-s-provider.aspx" target="_blank">open source second level cache for EF</a>!</p> <p>In brief, it’s a plug-in that intercepts EF requests to the EF “Store Provider” (the component that turns EF store queries into SQL queries on a database, be it SQL Server, Oracle, or something else). </p> <p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgmmbpfv-Odz-1p2TBi92MAV_isOXQ-EZp3CYp4XeX6bL9e1uGCb03sYjiaQHeFAKEntsaTaJ4rXJkBUXzHKG4aH1SftaUmFLuK7lNr4pp2K15YnMullDIsqfh0gzIxjbkJDiPOBnyoZNcN/s1600-h/clip_image0014.jpg"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="clip_image001" border="0" alt="clip_image001" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgvEE2oDiwd6v-JambHUsUwyQFERWAdjZJ0zrAALR6ANp_05pOzHI42jtNxHPR53Zy3BByFVOeMSBVHHqkquAy7tUkE51cXUBWBhGel8JFE4mK8Mk316dKiwcT5JigKPc_QfLqn-D7yrny-/?imgmax=800" width="530" height="260" /></a></p> <p>The second level cache checks if it’s holding results for that query; if so, it returns them from its cache, short circuiting the call to the database; if not, the query passes through to the Store Provider. Then the second level cache intercepts and caches the returned results for next time. I’m simplifying of course; you’ll want to dig into the resources mentioned below for full details.</p> <p style="background-color: #f8e4b0; margin-left: 20px; margin-right: 20px">Notice that the component includes a tracing interceptor as well.</p> <p>You don’t have to design your application for second level caching up front. You can add the second level cache component later … when you know you need it. It’s presence (or absence) is largely transparent to DevForce and EF. You’re just “wrapping” the Store Provider in this caching component; it looks like a normal Store Provider to EF.</p> <h2>Learn about Second Level Caching in EF</h2> <p>If this approach sounds like it would help, you can learn more about it from these sources:</p> <p><a href="http://msdn.microsoft.com/hi-in/magazine/hh394143(en-us).aspx" target="_blank">Second-Level Caching in the Entity Framework and Windows Azure</a> (Julie Lerman, Sept 2011)</p> <p><a href="http://blogs.msdn.com/b/adonet/archive/2010/09/13/ef-caching-with-jarek-kowalski-s-provider.aspx" target="_blank">EF Caching with Jarek Kowalski's Provider</a> (EF Team, Sept 2010)</p> <p><a href="http://blog.3d-logic.com/2012/03/31/using-tracing-and-caching-provider-wrappers-with-codefirst/" target="_blank">Using tracing and caching provider wrappers with Code First</a></p>Ward Bellhttp://www.blogger.com/profile/10977457957771020146noreply@blogger.com0tag:blogger.com,1999:blog-393540894130950585.post-6916411315423519542012-03-22T19:26:00.000-07:002012-04-27T13:04:42.593-07:00Squash Entity Framework startup time with pre-compiled views<h2>
In brief</h2>
Your application can stall for several minutes while Entity Framework gathers the information it needs to perform queries and saves, a lengthy process it performs twice: before the first query and before the first save. Those minutes pile up, wasting developer time and angering your customers. You can drastically reduce these delays by <a href="http://msdn.microsoft.com/en-us/library/bb896240.aspx" target="_blank">pre-compiling the Entity Framework’s “views”</a> of your model … as I explain in this post and demonstrate in its 14 minute accompanying video.<br />
<br/>
<iframe width="560" height="315" src="http://www.youtube.com/embed/qsm12syxRWs" frameborder="0" allowfullscreen></iframe><br/>
<br />
<h2>
Costly EF startup </h2>
If you’ve used Entity Framework for a line-of-business application model, you’ve suffered a lengthy delay before the first query completes and a similar delay before the first save completes. Subsequent queries and saves finish are much quicker, completing in an amount of time commensurate with the request.<br />
<br />
The delay is a <strong><em>non-linear</em></strong> function of the number of entities in the model. It often feels exponential. You probably won’t notice it in a toy model (every demo you’ll ever see) because the delay is lost in the wash of everything else that you’re thinking and learning about. But when the model grows to normal size – 100 or more entities – the delay mushrooms to a minute, two minutes or more. And you suffer this delay every time run the application … which you do all day, every day during development. Multiply that by the number of developers on the project and you’re wasting a lot of time … and money. <br />
<br />
The cost is far worse than the time lost. Make a developer wait two or three minutes per iteration and she’s bound to forget why she ran the app in the first place. Two minutes is a long time. The mind wanders. The mind turns to email, Twitter, and Facebook. Productivity is shot.<br />
<br />
Now I don’t think you should be going near a database during normal development iterations. I recommend that you toggle the app to run against an in-memory representation of your data layer such as the DevForce “Fake Backing Store”. But maybe you’ll disregard my suggestion. And everyone has to hit the database occasionally just to confirm that the app works end-to-end.<br />
<br />
So the development cost is terrible no matter what you do … unless your developers’ time is free; perhaps you price them at zero dollars and you’re response to every productivity decline is to hire more developers. Your second instinct is to outsource. <br />
<br />
What about your customers and internal end users? If the app runs 2-tier, they suffer the delay every time <strong><em>they</em></strong> launch the app. Does their time matter to you? I’ll bet someone will make sure it matters to you.<br />
<br />
<em>You won’t field customer complaints if your application runs n-tier (e.g., in a Silverlight application) because the Entity Framework runs on the server. The startup penalty is paid only by the first user to query and save. If you run n-tier and you don’t care about developer productivity, turn the page and move along.</em><br />
<br />
<h2>
Pre-compiled Views to the rescue</h2>
I’ve been wondering what to do about this for a long time. I’d heard that “<a href="http://msdn.microsoft.com/en-us/library/bb896240.aspx" target="_blank">Entity Framework Pre-compiled Views</a>” might help. I also had heard that it was troublesome and might not work. It seemed like one more thing to get around to someday.<br />
<br />
Then one of our professional services customers called and complained. His project had started fine but hit the wall at around 200 entity types. The first query and first save each took about 50 seconds on most machines. Team productivity had sunk, morale was sinking, and he was catching serious political flak internally. Our own staff confirmed that the problem was real. Since we (IdeaBlade) had recommended EF Code First, we had to do something. <br />
<br />
My colleague, Steven Schmitt, did the leg work that proved EF pre-compiled views (a) work for Code First models, (b) were easy to create, and (c) improved performance dramatically: the 50 second first query dropped to seven seconds; the 50 second first save dropped to less than one second.<br />
<br />
He deserves the credit … I’m taking the glory by blogging about it.<br />
<br />
The accompanying <a href="http://www.youtube.com/watch?v=qsm12syxRWs" target="_blank">14 minute video</a> shows EF’s slow launch times for a 200+ entity model, demonstrates how to create pre-compiled Views, and explains a bit about how they work.<br />
<br/>
I produced the video to spare you a parade of screen shots. I think it also conveys the seriousness of the problem and the practical benefit of pre-compiled Views more effectively than I can in spare prose.<br />
<p style="margin-left:20px; margin-right:20px; font-style: italic; background-color: #f8e4b0;">
The EF view generation tool does not work with EF 4.3 yet. Microsoft sources report that an update is in the works.</p>
For those of you who want just the facts, here they are:
<br />
<ol>
<li>Ensure that SQL Server Express is installed. You can get around it with a <em>DefaultConnectionFactory</em> but it’s such a pain. Save your energy for better things and just install the thing.<br /><br /></li>
<li>In Visual Studio 2010, open the Extension Manager (Tools | Extension Manager).<br /><br /></li>
<li>Search for “Entity Framework Power Tools”. The version as I write is “Entity Framework Power Tools CTP1 0.5.0.0”.<br /><br /></li>
<li>[optional] Review the <a href="http://visualstudiogallery.msdn.microsoft.com/72a60b14-1581-4b9b-89f2-846072eff19d" target="_blank">online information</a> about it. These tools do more than pre-compile EF views.<br /><br /></li>
<li>Locate your custom <em>DbContext</em> class in Solution Explorer [note: we’re describing how to pre-compile views for an EF Code First model. You follow a similar approach for an EDMX-based model although I haven’t tried it personally.]<br /><br /></li>
<li>Make sure that your <em>DbContext</em> class has a public parameterless constructor … or the tool will fail in a mysterious way.<br /><br /></li>
<li>Select your <em>DbContext</em> class, right-click, and select “Entity Framework”<br /><br /></li>
<li>Select the “Optimize Entity Data Model” sub-item<br /><br /></li>
<li>Wait … the tool takes a while to compile the "views”.<br /><br /></li>
<li>When it’s done, your <em>DbContext</em> has a companion <em>DbContext.Views</em> class file.<br /><br /></li>
<li>Build and run.</li>
</ol>
You should notice an immediate improvement in start time. There is still a delay before the first query completes. But it should be a fraction of the former delay … around 1/7th of the time. The delay for the first save should be gone; it takes no longer than the second save.
<br /><br />
<h2>
DevForce Developer Notes</h2>
Your <a href="http://ideablade.com/" target="_blank">DevForce application</a> benefits from EF Pre-compiled views when you follow these steps. A DevForce Code First model doesn’t have to have a custom DbContext class … but <a href="http://drc.ideablade.com/xwiki/bin/view/Documentation/code-first-dbcontext" target="_blank">you will have to create one</a> to use this tool.<br />
<br />
DevForce developers typically don’t define a parameterless constructor because DevForce wants a constructor that takes a connection string. Add the parameterless constructor anyway. Don’t worry, we will pickup the appropriate constructor at runtime.<br />
<br />
<h2>
When the model changes</h2>
Entity Framework detects if your entity model classes have changed since you compiled the EF views class. When you attempt your first query, you’ll get a clear runtime exception telling you to re-compile the views class.<br />
<br />
Only database-related changes to persisted data and navigation properties matter. You can add UI hint attributes (e.g., <em>[Display…]</em>) and non-persisted custom properties (e.g., <em>FullName</em>) without triggering an exception. Any change that would affect the mapping between your entity classes and the database will trigger the exception.<br />
<br />
How does EF know that the model has changed? I’m not certain but I have a pretty good guess. Ignore the views class filename and look at the name of the views class itself. It will be something like “<em>ViewsForBaseEntitySets72E6108A34B7DB042DBA3C465F35B967B4E3C76051DFBAB958B69CB0D23EA8B7</em>”. <br />
<br />
The hex suffix at the end looks like a hash. I’m guessing it is a hash of your entity model classes and that Entity Framework spends the initial seconds before the first query reflecting over and hashing your entity model classes before comparing that hash to this views class suffix. Inside the class itself are a couple more hash values. Maybe it's using those too or instead. Someday I'll find out. It's evident that its doing some kind of comparison between the entity model classes and this views class to ascertain if there is a disconnect.
<br/><br />
Anyway, at runtime, if EF detects a difference, it throws an exception which should terminate your app. You'll encounter the exception quickly and unmistakeably when your app first requests data. I presume that will be before you push to production :). Just re-run the tool and you should be back in business. <br />
<br />
At IdeaBlade we’re looking into a way to detect the views/model incompatibility at build time and regenerate the pre-compiled views automatically.<br />
<br />
Meanwhile, it’s good to know that EF fails fast when the pre-compiled views and your model are out of sync … and the remedy is as simple as re-running the tool.<br />
<br />
Hope this helps real-world EF developers everywhere.<br />
<br />
<h2>
Update - March 23</h2>
My buddy Steve Schmitt reminds me of a few more points.<br/>
<ul>
<li>Rowan Miller and the EF team deserve credit for developing the EF Power Tools; we just downloaded it.</li>
<li>There’s a bit more <a href="http://blogs.msdn.com/b/adonet/archive/2011/05/18/ef-power-tools-ctp1-released.aspx" target="_blank">info about the tool online</a>.</li>
<li>If you don’t want to regenerate the views for whatever reason, you can just delete the views file and you’re back to “normal”.</li>
</ul><br/>
<h2>
Update - April 6</h2>
The EF team published this month an important <a href="http://msdn.microsoft.com/en-us/data/hh949853" target="_blank">white paper on performance in EF 4 and 5</a> that bears on pre-compiled views and other tactics that could make a significant difference for your project.<br/>
<br/>Ward Bellhttp://www.blogger.com/profile/10977457957771020146noreply@blogger.com0tag:blogger.com,1999:blog-393540894130950585.post-38952634713438603542012-03-08T12:45:00.001-08:002012-03-09T15:52:08.581-08:00Synchronous tasks with Task<T>I extracted this thought from an email by Microsoft’s <a href="http://bradwilson.typepad.com/" target="_blank">Brad Wilson</a> and circulated within my company. Why not share it with you?<p>Brad starts with an important piece of advice: <strong>don’t make a synchronous activity async</strong>!</p><p>Ok, but how do you construct a Task<T> that you’ll consume within the context of a bundle of tasks? Brad shows how. Hey … thanks Brad!</p>
----- <br />
The following is an anti-pattern with tasks on a server:<br />
<pre class="csharpcode"><span class="kwrd">return</span> Task.Factory.StartNew(
() => model.Deserialize(stream, <span class="kwrd">null</span>, type));</pre>
This will run your code on a new thread, forcing a context switch, which is unnecessary because your code is fundamentally synchronous. If you’re going to run synchronously, you should just run synchronously, and return a TaskCompletionSource that’s populated with your result. For example:<br />
<pre class="csharpcode"><span class="kwrd">object</span> result = model.Deserialize(stream, <span class="kwrd">null</span>, type);
var tcs = <span class="kwrd">new</span> TaskCompletionSource<<span class="kwrd">object</span>>();
tcs.SetResult(result);
<span class="kwrd">return</span> tcs.Task;</pre>
If Deserialize might throw, then a version with try/catch would be a better implementation of the Task contract:<br />
<pre class="csharpcode"> var tcs = <span class="kwrd">new</span> TaskCompletionSource<<span class="kwrd">object</span>>();
<span class="kwrd">try</span>
{
<span class="kwrd">object</span> result = model.Deserialize(stream, <span class="kwrd">null</span>, type);
tcs.SetResult(result);
}
<span class="kwrd">catch</span>(Exception ex)
{
tcs.SetException(ex);
}
<span class="kwrd">return</span> tcs.Task;</pre>
<h3>What do you mean by "fundamentally synchronous"?</h3><br/>I can assure you that the Deserialize method in question is synchronous.
<pre class="csharpcode">model.Deserialize(stream, <span class="kwrd">null</span>, type));</pre>
That expression blocks until it returns the deserialized object. You see the <i>stream</i> parameter and think "this should be an asynchronous method". Maybe it should be, smarty pants; come back when <b>you</b> have written a deserializer that can reliably produce an object graph without reading the entire stream first.<p>While we're waiting for your <i>DeserializeAsync</i> implementation, let's push on the proposition that we should <b>not</b> move the execution of <i>Deserialize</i> to another thread.</p><p>Clearly, if this method is reading a stream, it could take "a long time" to complete. If we are running on the client, we'll freeze the UI until the deserialization completes. That can't be good. And it isn't. If we're running on the client, you <b>should</b> consider moving the execution of this method to another thread.</p><p>In this case, we're running on the server. There is no user waiting for the method to return so we don't care about speed on any particular thread. I'm sure the client cares about a fast response but the response isn't coming until the work is done ... on one thread or another.</p><p>We <b>do</b> care about total server throughput. We gain nothing by moving execution to another thread; in fact, we <b>lose</b> because of the thread context switching cost. This is why Brad says that spawning a new task with "Task.Factory.StartNew" is "an anti-pattern ... <i>on a server</i>". It's cool on the client; not cool on the server.</p><h3>I'm ready with <i>DeserializeAsync</i>; now what?</h3><p>Should we invoke the async method within a delegate passed to "Task.Factory.StartNew"? No, we should not!</p><p>This surprised me too ... until someone walked me through it ... until someone asked me "what do you think will happen on the thread you spawn?" I realized that all I would do on that new thread is dream up some way to wait for <i>DeserializeAsync</i> to finish. Of course <i>DeserializeAsync</i> spawns its own thread so I've got an original thread waiting for my task thread which is waiting for the <i>DeserializeAsync</i> thread. That's a complete waste of time ... and a pointless, resource-wasting context switch.</p><h3>What's the point of TaskCompletionSource?</h3><p>We're in this situation because for some (good) reason we want to expose a method - synchronous or asynchronous - as a <b>Task</b>. We don't want or need to spawn a new thread to run that method. We just want to consume it as a Task. The <i>TaskCompletionSource</i> is the wrapper we need for this purpose. It lets us return a Task object with the Task API that we, like puppeteers, can manipulate while staying on the current thread.</p><p>For another, perhaps better, and certainly excellent explanation of this, I recommend the following <a href="http://channel9.msdn.com/Blogs/philpenn/TaskCompletionSourceTResult" target="_blank">Phil Pennington video on TaskCompletionSource</a>. Happy coding!</p>Ward Bellhttp://www.blogger.com/profile/10977457957771020146noreply@blogger.com7tag:blogger.com,1999:blog-393540894130950585.post-71867540859255884452011-11-11T14:03:00.001-08:002011-11-12T16:03:23.812-08:00Build business apps in .NET - not HTML & JavaScript<p>A lot of people are freaking out about the apparent decline of .NET client technologies such as WPF and Silverlight. I’m one of those people. How can one, in good conscience, advocate new development in WPF or Silverlight (or Windows Forms)?</p> <p><strong><span style="font-size: small">Well I can advocate it, I do advocate it, and I’m sleeping well at night.</span></strong></p> <p>A recent comment to one of <a href="http://neverindoubtnet.blogspot.com/2011/10/windows-8-metro-apps-in-javascript.html">my post on WinRT</a> provoked an outsized reaction that has become this post. Here’s that comment:</p> <blockquote><em><span style="font-size: small">Given that most people who are skilled in HTML5+JS write applications that are cross-browser and cross-OS every day; why would they ever consider writing for a single OS?</span></em></blockquote> <p>This fellow managed to capture in a few words the current mood and madness. My rant follows:</p> <h2>Who are you kidding?</h2> <p>First, hardly anyone is skilled in HTML <span style="background-color: yellow"><strong><u>5</u></strong></span>. Period. That’s just wrong on the facts.</p> <p>Secondly, most people “<em>who are skilled in HTML + JavaScript</em>” – cross-browser or otherwise - <strong>do not have a clue how to write a business application in JavaScript</strong>.</p> <p>Most people who write apps that emit HTML do not write much JavaScript; they exploit controls that rely on JavaScript and they may write a little decorative JavaScript but that's the extent of their experience.</p> <p>How do I know that? I've been hanging out where the experts in JavaScript hang ... and the recurring verities are (a) most people write horrible JavaScript (hence the need for Crockford's "JavaScript - The Good Parts"), the apps are almost unmaintainable when they do, and (c) the appropriate design and implementation patterns for JavaScript are in flux.</p> <p>This is a fascinating and creative time in the evolution of JavaScript programming. New frameworks are popping up left and right. Lots of lectures and discussions about how to do it right. That's all healthy.</p> <p>But the sheer wildness and variety of competing and overlapping toolkits/frameworks/guidance <strong>reveals the immaturity of the JavaScript environment as a business application development platform</strong>.</p> <h2>Get real about business application development</h2> <p>Let me be crystal clear about what I mean when I talk about a "business application" … because I want to confine my remarks to just this one kind of app. I take a completely different position on the appropriate development and delivery platform for other kinds of applications. <strong>This post is about business applications only</strong>.</p> <p>[<span style="font-size: small"><strong>Warning</strong>: <strong>I will delete every comment</strong></span> that attempts to refute my argument by reference to any other kind of application. I will be especially dismissive of counter-claims which only make sense with regard to consumer facing, social networking, content broadcasting apps. You are simply not paying attention if you respond in that way and I will not waste my time or my reader(s) time with your inappropriate reply.]</p> <p>Here is what I mean by a “business application”:</p> <ol> <li>It is a "<strong><span style="font-size: small">sovereign app</span></strong>". That one app will dominate a user's attention for hours at a time, day after day. <br /> <br /></li> <li>The <strong><span style="font-size: small">user is paid to use the app</span></strong>. The person who pays him/her requires that user to get work done with the app as quickly and efficiently as possible. <br /> <br /></li> <li>It is <strong><span style="font-size: small">data-centric</span></strong>. The user consumes a large volume and <strong>variety</strong> of data. More importantly, the user routinely adds and updates that data in all of its variety. <br /> <br /></li> <li>Therefore, the app must be<strong> <span style="font-size: small">highly responsive and immersive</span></strong> in order to maximize user productivity. It must present data and accept user input at top speed. Every moment spent waiting or wondering or searching around or flipping pages is wasted user time and wasted business owner money. </li> </ol> <p>In my experience, the only apps that hit the required standard of user efficiency are apps that execute predominantly on the client. I don't care if its written in Windows Forms, WPF, Silverlight, Java, or in JavaScript ... it has to execute on the client and make only the minimally necessary trips to the server. </p> <p>This is the context for answering your question. <strong><em><span style="font-size: small">Why would I write for one OS?</span></em></strong></p> <p>If I'm writing a business app, in all likelihood there is only one OS that matters: Windows. Windows just happens to own 95% of my targeted user base (my estimate) ... today and for the near term. </p> <p>[Note: The <a href="http://en.wikipedia.org/wiki/Usage_share_of_desktop_operating_systems#Estimates_for_2011">OS-on-a-PC figures</a> are imperfect but the consensus is that Windows has no less than 88% share of all PCs which includes home PCs. Home PCs don’t matter for this analysis.] </p> <p>Don't bother telling me about mobile. Don't bother giving me statistics on web traffic by OS (where <a href="http://marketshare.hitslink.com/operating-system-market-share.aspx?qprid=8">Windows gets 86% of 2011 web traffic</a>, btw). Don't tell me your vision for the future. This discussion is about business apps today and they run on PCs ... period.</p> <p>If the time & cost of developing and maintaining business apps in HTML/JS were anywhere close to the marks of a .NET client platform I'd say "go HTML/JS".</p> <p>But they aren't. Not close. Not soon to be close. And that fact is nowhere in dispute, not even among the most ardent HTML/JS fans.</p> <p>So, as a business person, I've got a decision to make. The economics of today tell me "build it in .NET" because I can do it cheaply, effectively, with great quality using readily available resources, mature tools and experienced developers.</p> <p>Of course, as a business man, I'll be concerned about the future and the long-term viability of my application. I’m perturbed that the app I am building today will be seen in 3 years as pinned to a legacy technology. That's a tough pill ... and it's why there is so much consternation. No one wants the “legacy” sign hanging around his neck.</p> <p>But it’s not like everyone is going to forget how to write in .NET. Support won’t vanish. I will be able to find technology and people to keep the application alive in ten or fifteen years. I’ve got time to amortize my development costs and prepare for the inevitable transition(s) down the road.</p> <p>The alternative - writing a business app in HTML/JS today – makes no economic sense. It doesn’t give me more reach because there are virtually no targeted users that I can’t reach today and for years to come. They are running Windows. </p> <p>For sure the application will take 2 to 3 times as long to build in HTML/JS. I don’t have – nor can I find - the developers with the skills and experience for building an app like mine. The tools and frameworks they need don’t quite exist yet; the current prototypes are re-released with breaking changes every couple of months. My developers will be following half-baked implementation regimes, borrowed from other platforms (… oh, like .NET), that are as yet unproven for JavaScript business apps.</p> <p>Yes … I could trust my critical business application development to HTML+JavaScript … if I’m a nutter.</p> <h2>Summary</h2> <p>Let me net it out for you:</p> <ul> <li>A tiny % of today's developers are capable of writing an HTML/JS business application. <br /> <br /></li> <li>There are almost no examples of such apps today and almost no place to go to learn how to make them. <br /> <br /></li> <li>For most business apps there is only one OS that matter: Windows <br /> <br /></li> <li>The economics of developing a business app that runs on Windows are vastly superior to the economics of developing a business app in HTML/JS. </li> </ul> <p>All that can change. All that <strong><em>will</em></strong> change. But not this year, not next year, and maybe not in 2013 either.</p> <p>If you have the luxury of screwing around, have fun in HTML/JS. I know that I have that luxury and I am, indeed, having fun.</p> <p>If you must write a business app for delivery in the next 12 months, do it in a .NET client technology.</p> <h2>Update 11/12</h2> <p>A discussion of this post has emerged on <a href="https://plus.google.com/u/0/118303283951449952966/posts/iQG1JWqENZX?hl=en#118303283951449952966/posts/iQG1JWqENZX">a G+ thread</a> that you may find entertaining or even illuminating.</p> Ward Bellhttp://www.blogger.com/profile/10977457957771020146noreply@blogger.com45tag:blogger.com,1999:blog-393540894130950585.post-77491927310985985602011-11-03T10:56:00.001-07:002011-11-03T11:17:12.425-07:00DevForce Code First with AOPWe recently released <a href="http://www.ideablade.com/">DevForce 6.1.3</a> whose signature feature is Code First development of a distributed entity model, implemented with Aspect Oriented Programming (AOP). Let me unpack that for you.<br />
<br />
<strong>Code First</strong> – You write the entity classes and only the entity classes. You don’t use a visual designer. You let the Entity Framework map your classes by convention to database objects and clarify in code those mappings that can’t be inferred.<br />
<br />
<strong>Distributed Entity Model</strong> – “Distributed” is the key word: in a DevForce application, the client may have to rely on an intermediary server to reach the database. In DevForce, you program with a single set of entity classes, the classes you wrote, on both the server and client. DevForce handles the coordination and movement of data across tiers and over the network. The client could be Windows Forms, WPF, or Silverlight. The server could run as a Windows Service, in IIS, or in Azure. The network could be a LAN or the web.<br />
<br />
<strong>Aspect Oriented Programming</strong> – Who needs change notification, property validation, change tracking, lazy loading, client-side caching? <strong>You do</strong> … if you want to query, save, and bind a WinForms or XAML UI directly to your interrelated collections of entities. That takes infrastructure (<em>INotifyPropertyChanged</em>, <em>INotifyDataErrorInfo</em>, etc) that you should not write yourself. Where is that infrastructure hiding when your source code only says: <span style="font-family: Consolas;"><em>public string Name {get; set;}</em></span>? It’s inside your entity model assembly, after we rewrote it with <a href="http://www.sharpcrafters.com/">PostSharp</a>. The infrastructure you need is ready at runtime.<br />
<br />
You can <a href="http://drc.ideablade.com/xwiki/bin/view/Documentation/code-first">read all about DevForce Code First here</a>. There’s a six part <a href="http://drc.ideablade.com/xwiki/bin/view/Documentation/code-sample-code-first-walk">walkthrough of a WPF sample here</a>. Right now, I want to talk about why I am personally jazzed about the DevForce Code First approach.<br />
<h2>
Why Code First?</h2>
<br />
DevForce has long been friendly to Entity Framework. Heretofore, we integrated closely with the Entity Data Model Designer in Visual Studio and relied upon the resultant EDMX file as the basis for generating entity classes with our own T4 template (which you can customize). That approach is still enormously popular and we remain enthusiastic about it.<br />
<br />
But I am smitten by our new Code First option. I like Code First because I think it can <strong>reduce the friction</strong> of developing and maintaining my entity model. Let me show you a <strong><em>Product</em></strong> class I wrote in Code First:<br />
<pre class="csharpcode">[ProvideEntityAspect]
<span class="kwrd">public</span> <span class="kwrd">class</span> Product
{
<span class="kwrd">public</span> <span class="kwrd">int</span> ProductId { get; set; }
<span class="kwrd">public</span> <span class="kwrd">string</span> ProductName { get; set; }
<span class="kwrd">public</span> <span class="kwrd">int</span> CategoryId { get; set; } <span class="rem">// Foreign key for "Category"</span>
<span class="kwrd">public</span> Category Category { get; set; }
<span class="kwrd">public</span> Guid SupplierKey { get; set; } <span class="rem">// Foreign key for "Supplier"</span>
<span class="kwrd">public</span> Supplier Supplier { get; set; }
}</pre>
<style type="text/css">
<br /><br /><br />.csharpcode, .csharpcode pre<br />{<br /> font-size: small;<br /> color: black;<br /> font-family: consolas, "Courier New", courier, monospace;<br /> background-color: #ffffff;<br /> /*white-space: pre;*/<br />}<br />.csharpcode pre { margin: 0em; }<br />.csharpcode .rem { color: #008000; }<br />.csharpcode .kwrd { color: #0000ff; }<br />.csharpcode .str { color: #006080; }<br />.csharpcode .op { color: #0000c0; }<br />.csharpcode .preproc { color: #cc6633; }<br />.csharpcode .asp { background-color: #ffff00; }<br />.csharpcode .html { color: #800000; }<br />.csharpcode .attr { color: #ff0000; }<br />.csharpcode .alt <br />{<br /> background-color: #f4f4f4;<br /> width: 100%;<br /> margin: 0em;<br />}<br />.csharpcode .lnum { color: #606060; }
</style><br />
<em>Product</em> has six properties: the key (<em>ProductId</em>), a name, two foreign keys (<em>CategoryId</em>, <em>SupplierId</em>) and two “navigation properties” that return related parent entities (<em>Category</em>, <em>Supplier</em>). There’s no base class … unless I want one. The only evidence of infrastructure is that peculiar <em>ProvideEntityAspect</em> attribute … to which we will return.<br />
<br />
This code is obvious and easy to write. The class conforms to Entity Framework <a href="http://msdn.microsoft.com/en-us/library/hh161541%28v=VS.103%29.aspx">naming conventions</a> so there is no need for explicit mapping with <a href="http://msdn.microsoft.com/en-us/library/gg197525%28v=VS.103%29.aspx">attributes</a> or the <a href="http://msdn.microsoft.com/en-us/library/hh295844(v=VS.103).aspx">fluent API</a> at this point. You’re welcome to add explicit mapping as you choose or need to do so. I didn’t need to … and I prefer to stick with the conventions.<br />
<br />
I hammered out this class as it occurred to me. I didn’t fire up the EDM Designer in Visual Studio. I don’t have an EDMX file to manage. No partial classes separate the generated code from my custom entity business logic (of which there is none at the moment but it’s coming). There are no companion metadata classes for manipulating attributes of generated properties. There is no code generation for Silverlight clients as there is in RIA Services. The entity source code you see is the same source code living in all .NET server and client environments.<br />
<br />
I can evolve this class as I go … with or without a pre-existing database. I can add validation attributes when and where I want them. Or I can add <em>Product</em> <a href="http://drc.ideablade.com/xwiki/bin/view/Documentation/validate">validation rules</a> separately if I don’t want them buried in the entity. I can write DevForce <a href="http://drc.ideablade.com/xwiki/bin/view/Documentation/property-interceptors">property interceptors</a> to inject behavior when a Product consumer gets or set any of these properties. What begins as little more than a property bag can grow to have as much (or as little) business logic as I think the entity requires … without touching the properties; they remain exactly as you see them.<br />
<br />
I can write tests for my added business logic - including tests that exercise the navigations from <em>Product</em> to <em>Category</em> and <em>Supplier</em> – without ever contacting a server or a database.<br />
<br />
I’m focused on the <em>Product</em> class and just what it needs to function properly in my business domain. The infrastructure is invisible … although accessible when I want it.<br />
<br />
It’s not zero friction. But it’s as frictionless an approach to entity model development as I’ve seen. Which means I should be able to move my development forward faster, with higher quality, and a better chance of conveying my intentions clearly to the developer who picks up after I’ve left the project.<br />
<br />
<h2>
Beyond Entity Framework</h2>
<br />
At first blush, what I’ve described … the <em>Product</em> class I’ve shown … could come straight out of an Entity Framework tutorial. If you add .NET validation attributes to the properties, Entity Framework will perform object validation for you and reject attempts to save invalid entities. These DevForce entities actually are ready-to-go as Entity Framework entities. What value is DevForce adding that’s not already in Entity Framework?<br />
<br />
DevForce brings two huge advantages:<br />
<ol>
<li>DevForce entities are queried and saved in n-tier deployments … such as Silverlight and cloud applications.<br /> </li>
<li>DevForce entities are equipped to participate in Windows Forms, WPF, and Silverlight UIs.</li>
</ol>
<strong>Native Entity Framework is a strictly 2-tier technology</strong>. The client must have line-of-sight to the database. You can’t serialize and de-serialize entity graphs across the web. You can’t compose LINQ queries on a remote client. You can’t query asynchronously and manage exceptions remotely. You can’t prepare change-sets remotely and save them remotely. Such capabilities become possible only if you write a ton of difficult infrastructure … or use DevForce.<br />
<br />
You are welcome to march into the wilderness on your own. Go write and maintain the myriad services that shuffle data into and out of DTOs (Data Transfer Objects). Try that on today’s line-of-business application with its hundreds of interrelated entities and see how much time you waste on those subterranean layers while the UI languishes and your customer taps his toes.<br />
<br />
If you stay 2-tier and you’re pushing entity data into an ASP Web Form, the native Entity Framework entity may be good enough. Your UI controls can translate the validation attributes to JavaScript. You have little use for property change notification. You’re web server has line-of-sight to the database and can run EF on its full .NET stack.<br />
<br />
<strong>That is</strong> <strong>not good enough for Windows Forms, or WPF, or Silverlight</strong> … the preferred client environments for line of business applications. These client technologies favor bi-directional data binding. Their controls listen for the <em>PropertyChanged</em> event to fire when something sets the property of a bound entity object. Many grid controls respond to hints they discover in attributes decorating the entity properties. Many controls can cancel and roll back user changes automatically if the entity supports <em>IEditableObject</em>. They can light up with validation error information when the entity supports <em>IDataErrorInfo</em> or <em>INotifyDataErrorInfo</em>.<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhQLuwgF80RfOwvzhzln8tnxRbdj1mDbPhuJyWc3bpLDCj-MJIR5W6afNSjjMzqCuocxW7RK4WGFaw0ofU2kP8NUF8WU6t2fchtr-ic0xrb0tgx1UdVbCXeAa-QnYfe85PtAAAH0U_PNo9f/s1600-h/image%25255B13%25255D.png"><img alt="Entity Validation in WPF" border="0" height="166" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh7sPp9ti906bUYWsIDel_J8XGlafN7mlots8MKtAsm-fZfqekd1nfiFNi5kTEmaseecLL3Be9_Kx8bx8wCaQJyfhVfLK8qn3qZ4YfobuzZSVjIObiF_x4NXZ9DmBh59Gyhuf-bGmKbaw0t/?imgmax=800" style="background-image: none; border-width: 0px; display: inline; padding-left: 0px; padding-right: 0px; padding-top: 0px;" title="Entity Validation in WPF" width="685" /></a><br />
<br />
<em>In this </em><a href="http://drc.ideablade.com/xwiki/bin/view/Documentation/code-sample-code-first-walk"><em>WPF sample</em></a><em> screen shot, the “Supplier” text box is bound to the <strong>Product.Supplier.CompanyName</strong> property. DevForce navigates from the <strong>Product</strong> to the <strong>Supplier</strong> instance in cache. The user entered a value in mixed case (“All Fine Foods has a name that is far too long”). A “get-interceptor” converts the value to uppercase before returning it to the text box. The property validation mechanism immediately applies the property length validation rule and records the rule violation. The binding, which detects that Product implements <strong>IDataErrorInfo</strong>, displays the validation message.</em><br />
<br />
Developers want their entities to provide this kind of support automatically. They don’t want to write it. They don’t want to see it. Developers are really tired of writing … or wading through … pages of property definitions such as<br />
<br />
<pre class="csharpcode"><span class="kwrd">public</span> <span class="kwrd">string</span> ProductName
{
get { <span class="kwrd">return</span> _productName; }
set
{
<span class="kwrd">if</span> (_productName != <span class="kwrd">value</span>)
{
<span class="kwrd">if</span> (Validate(<span class="kwrd">value</span>))
{
_productName = <span class="kwrd">value</span>;
RaisePropertyChanged(<span class="str">"ProductName"</span>);
}
}
}
}
<span class="kwrd">private</span> <span class="kwrd">string</span> _productName;</pre>
<style type="text/css">
<br /><br /><br />.csharpcode, .csharpcode pre<br />{<br /> font-size: small;<br /> color: black;<br /> font-family: consolas, "Courier New", courier, monospace;<br /> background-color: #ffffff;<br /> /*white-space: pre;*/<br />}<br />.csharpcode pre { margin: 0em; }<br />.csharpcode .rem { color: #008000; }<br />.csharpcode .kwrd { color: #0000ff; }<br />.csharpcode .str { color: #006080; }<br />.csharpcode .op { color: #0000c0; }<br />.csharpcode .preproc { color: #cc6633; }<br />.csharpcode .asp { background-color: #ffff00; }<br />.csharpcode .html { color: #800000; }<br />.csharpcode .attr { color: #ff0000; }<br />.csharpcode .alt <br />{<br /> background-color: #f4f4f4;<br /> width: 100%;<br /> margin: 0em;<br />}<br />.csharpcode .lnum { color: #606060; }
</style><br />
That’s all noise and no business value. It should be quieter and simpler:<br />
<pre class="csharpcode"><span class="kwrd">public</span> <span class="kwrd">string</span> ProductName { get; set; }<style type="text/css">
.csharpcode, .csharpcode pre<br />{<br /> font-size: small;<br /> color: black;<br /> font-family: consolas, "Courier New", courier, monospace;<br /> background-color: #ffffff;<br /> /*white-space: pre;*/<br />}<br />.csharpcode pre { margin: 0em; }<br />.csharpcode .rem { color: #008000; }<br />.csharpcode .kwrd { color: #0000ff; }<br />.csharpcode .str { color: #006080; }<br />.csharpcode .op { color: #0000c0; }<br />.csharpcode .preproc { color: #cc6633; }<br />.csharpcode .asp { background-color: #ffff00; }<br />.csharpcode .html { color: #800000; }<br />.csharpcode .attr { color: #ff0000; }<br />.csharpcode .alt <br />{<br /> background-color: #f4f4f4;<br /> width: 100%;<br /> margin: 0em;<br />}<br />.csharpcode .lnum { color: #606060; }<br />
</style></pre>
<br />
Let’s push it a bit farther and think about what must be going on inside a property that returns a related entity. Here is how you write the <em>Product</em>’s <em><strong>Category</strong></em> property in DevForce Code First:<br />
<br />
<pre class="csharpcode"><span class="kwrd">public</span> Category Category { get; set; }</pre>
<style type="text/css">
<br /><br /><br />.csharpcode, .csharpcode pre<br />{<br /> font-size: small;<br /> color: black;<br /> font-family: consolas, "Courier New", courier, monospace;<br /> background-color: #ffffff;<br /> /*white-space: pre;*/<br />}<br />.csharpcode pre { margin: 0em; }<br />.csharpcode .rem { color: #008000; }<br />.csharpcode .kwrd { color: #0000ff; }<br />.csharpcode .str { color: #006080; }<br />.csharpcode .op { color: #0000c0; }<br />.csharpcode .preproc { color: #cc6633; }<br />.csharpcode .asp { background-color: #ffff00; }<br />.csharpcode .html { color: #800000; }<br />.csharpcode .attr { color: #ff0000; }<br />.csharpcode .alt <br />{<br /> background-color: #f4f4f4;<br /> width: 100%;<br /> margin: 0em;<br />}<br />.csharpcode .lnum { color: #606060; }
</style><br />
It is as plain, expressive, and simple as <em>ProductName</em>. We have the same need for validation and notification. We have two additional requirements, neither of them met by Entity Framework: (a) we must <strong><em>have</em></strong> the machinery for retrieving, caching and saving the related <em>Category</em> entity on a remote client and (b) we must <strong><em>plug</em></strong> that machinery into the property’s get and set methods at runtime. <br />
<br />
The apparent innocence of the <em>ProductName</em> and <em>Category</em> properties is possible thanks to some nifty work behind the curtain.<br />
<br />
<h2>
Aspect Oriented Programming (AOP)</h2>
<br />
DevForce makes writing properties as simple as shown while endowing them with the capabilities necessary for participation in the .NET client UI technologies. Clearly the “<em>property as shown</em>” cannot be the actual implementation at runtime. Somehow the infrastructure code has to insinuate itself into the property. <br />
<br />
DevForce uses <a href="http://www.sharpcrafters.com/">PostSharp</a> and Aspect Oriented Programming (AOP) to inject the infrastructure into your classes. It re-writes the compiled model assembly at build time. That <em>ProvideEntityAspect</em> attribute adorning the top of the <em>Product</em> class tells DevForce that <em>Product</em> is a kind of entity and should implement the behaviors that all entities exhibit. DevForce and PostSharp replace the <em>get</em> and <em>set</em> methods of entity properties with code that ties into DevForce infrastructure. The revised <em>Product</em> class inherits from and implements the interfaces that light up the UI controls. It also acquires support for querying, caching, change-tracking, and saving product data. The <em>Product</em> class, after re-write, is an enriched version of the original <em>Product</em> class you wrote. The <em>Product</em> objects that you “new” at runtime are instances of the enriched <em>Product</em> class. When a binding reflects into an instance of <em>Product</em>, it finds the interfaces it’s looking for.<br />
<br />
Many frameworks, including Entity Framework and NHibernate, use an alternative approach called “dynamic proxies.” They leave the original compiled classes alone. Instead, they rely on an external component (e.g., a “Context” or “Session”) to encase new and queried entities in a wrapper class that derives from your entity class. This wrapper overrides your entity’s properties with implementations that delegate (“proxy”) to the framework’s infrastructure.<br />
<br />
That infrastructure, if expanded appropriately, could do all of the interception, routing, and notification that DevForce does. You’d have to adapt your entity and workflow to play along. All of your entity properties would have to be virtual. You couldn’t construct them directly with “new”; in fact, you’d have to be careful always to reference the proxied object. You’d also have to get used to debugging with strange wrapper types, sporting bizarre long names.<br />
<br />
We like the AOP approach better. We think most people will find it more natural to work with a class that is fully baked at build time rather than maneuver to consume proxies that are emitted dynamically at runtime.<br />
<br />
<h2>
Could this be magic?</h2>
<br />
“<em>I don’t trust all that magic!</em>'” That’s a common early reaction to Code First, AOP (and dynamic proxies). When I rely on Entity Framework naming conventions to map class and property names to tables and columns, how do I know what it did or did not map? When AOP is injecting logic into my classes that I can’t see, how do I know what it is doing?<br />
<br />
I push the button on my coffee maker and good, hot brown stuff pours into my cup. That’s magic to me. The compiler turns my auto-property into two <em>get</em> and <em>set</em> methods with a backing field. That’s magic. Then it becomes IL code which becomes machine code which makes the hardware jump. That’s magic.<br />
<br />
The difference is that coding by convention and AOP are <em>new</em> magic for most of us. We’re used to the <em>old</em> magic. We probably never truly understood it; we just stopped worrying about it. Before, when the property code was visible and the entity-data map was in an EDMX file, we felt the visceral comfort of touching the code and displaying the XML if we wanted to. But we rarely wanted to. When we did look, we were as often confused by what we saw as not.<br />
<br />
What matters most is good diagnostics and easy debugging. I need a clear explanation when things go wrong and I need to know what to do about it. Fortunately, the Entity Framework mapping error messages are pretty good. I think the AOP debugging experience will feel familiar to you. You breakpoint your custom code exactly as you did before. You step through your code as you did before. You test your code as you did before.<br />
<br />
I am keen to know what you think after you’ve tried it. We’re eager to hear your suggestions. IdeaBlade issues DevForce updates every six-to-eight weeks so we can respond quickly.<br />
<br />
<h2>
What about existing databases?</h2>
<br />
I often hear that Code First is only for “<strong>greenfield</strong>” development and small database schemas. Perhaps half of our customers (re)build existing applications for existing databases with hundreds of tables some of which have hundreds of columns. Heaven help them.<br />
<br />
Such “<strong>brownfield</strong>” development presents at least three challenges:<br />
<ol>
<li>Getting started … because no one wants to write all those entities by hand. </li>
<li>Evolving the entity model and a production database as requirements change. </li>
<li>Keeping the model and the database in sync without the assistance of the EDM Designer.</li>
</ol>
We meet the first challenge with an approach we call “<a href="http://drc.ideablade.com/xwiki/bin/view/Documentation/code-second">Code Second</a>”. Speaking schematically, you aim the EDM Designer at the database and generate DevForce “Code First” classes. Then you throw away the EDMX file and proceed in Code First style.<br />
<br />
I’m optimistic but less confident in my response to the second and third challenges. I know developers in other communities (NHibernate in particular) have confronted these demons and wrestled them to the ground. They’ve survived without Database First tooling as far as I can tell. I’m betting they’ve discovered successful practices we can learn from and adapt.<br />
<br />
Code First style entails evolving the model and existing database in small doses, supported by tests. Runtime mapping exceptions are sufficiently informative in the context of small changes; repairing small breaks should be easy. You shouldn’t wake up in shocked surprise one morning to find that the model or the database have been massively transformed. That’s a disaster for Database First as much as Code First; it indicates far more fundamental flaws in your development process.<br />
<br />
A new module may require many new entity types to support its scenarios. The new entity types can be related to other types, new and existing. The new model ultimately translates to new tables and foreign key relationships to new and existing tables. I think I would develop a new module as I would a “greenfield” project with stubbed stand-ins for the existing entities and tables.<br />
<br />
It may be wise to preserve this separate model and separate database … forever. But if that’s not in the cards, when the new project matures, I’d fold my Code First model into the existing model. I’d script database changes from the generated Code First design database and apply them to the existing database.<br />
<br />
I readily admit that I do not have the concrete experience to back up these suggestions. I expect to have more to say on this subject in future posts. One of our customers hired us to help them rebuild their 500 table application in DevForce Code First. I promise to report back on do’s and don’ts.<br />
<br />
<h2>
What next?</h2>
<br />
I’d love to know what you think. Is Code First attractive to you? Do you have pros and cons to share? Would you <a href="http://drc.ideablade.com/xwiki/bin/view/Documentation/code-sample-code-first-walk">explore our walkthrough</a> and give me your feedback? Is there something that bothers you about what I’ve said? Anything you want me to expand upon?<br />
<br />
I’m here for you.Ward Bellhttp://www.blogger.com/profile/10977457957771020146noreply@blogger.com5tag:blogger.com,1999:blog-393540894130950585.post-35250946726358832652011-10-10T14:35:00.001-07:002011-10-10T19:06:06.363-07:00Windows 8 Metro apps in JavaScript<p>I’m having a blast exploring Windows 8 Metro app development and poking around in the preview bits shipped at the <strong><a href="http://www.buildwindows.com/">2011 BUILD conference</a></strong>.  Last weekend, I presented on Metro app development using <strong>JavaScript</strong> at the <a href="http://www.siliconvalley-codecamp.com/">Silicon Valley Code Camp</a>.</p> <p>I’ve <a href="http://drc.ideablade.com/xwiki/bin/view/Documentation/windows-8-metro-javascript">posted the sample code, my presentation script, and my slide deck on the IdeaBlade wiki</a>. </p> <p>I have not gone crazy and transferred my affections from .NET to JavaScript. I’m just curious about all the hub-bub. It’s also the only fair way to confront the assertions that JavaScript has grown up and that we’ll all soon be JavaScript programmers.</p> <p>What is all this noise about “programming in standards-based HTML5 and JavaScript” … which is technically possible in Windows 8 … although in practice you’ll be so imbricated in Windows that you might as well have written it in COM.</p> <p>I exaggerate … slightly. I’m not being critical though. You want to program for the iPad? You’ll use Objective C. For the Android? You’ll write in Java. At least for a Windows 8 device you can write your app in Javascript … or C++ … or C#/VB. The languages are (mostly) open; the application code is locked in.</p> <p>I had tons of fun following along with <a href="http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-501T">Chris Tavares and Chris Sells</a> as they built a Metro RSS Reader in JavaScript. The resulting demo app looks like this:</p> <p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEguUImNmXpfrKyYupyjZ8LhgnqQYRYfSrELNpoD27D2FV9C97zowednJh9k-gjzXH4m2HxV6v5RhJUHfMtQIXlSeeOAmipyu3PNoHnK3M_3NE8-djcT_ys6Vi7WDXNfs_Q7izSKpGeQYXdE/s1600-h/WinJsDemo-Part%2525205%25255B4%25255D.png"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="WinJsDemo-Part 5" border="0" alt="WinJsDemo-Part 5" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi-KtV-g_FKM_ChrWo-ra0KQgksnIVBLKzupDy4ikjLSg_MjNTUXhK-MHmtblpdkPLfsPnEfXpb6Z2neln5i75mFKLCPBbXJL4ILnoODcMYg4mjzAmoH8Ls5n9FQGKoSX6lSSndl8nOq9Fc/?imgmax=800" /></a></p> <p>I <strike>stole</strike> borrowed almost everything I showed from <a href="http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-501T">Chris’ talk</a> … unless I pinched it from <a href="http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-533T">Luke Hoban’s talk</a>. </p> <p>It’s always a kick to take a new technology out for a spin. The Microsoft folks are doing wonders with JavaScript on Windows but it’s still a dog walking on hind legs and always will be. I get … and approve of … what they’re doing: embracing the fresh faces coming out of school who “know” (be very wary of that verb!) HTML and JavaScript … not C#. That’s smart business.</p> <p>I expect to keep playing with JavaScript and writing about my experiences. I’m sure that it’s the perfect tool for many jobs. HTML and JavaScript (of a more general variety) <strong><em>may turn out to be</em></strong> the universal solvent for cross-vendor mobility apps.</p> <p>But not now and not soon. When it’s time to get serious about writing business applications, I’m sticking with the XAML technologies, Silverlight especially. Far more productive, less painful, and less risky in the hands of muggles … which is to say, most of us.</p> Ward Bellhttp://www.blogger.com/profile/10977457957771020146noreply@blogger.com9tag:blogger.com,1999:blog-393540894130950585.post-7718283242239044242011-09-22T22:24:00.001-07:002011-09-23T08:26:24.332-07:00“Desktop” could be Win 8’s killer feature with consumers<p>Crazy? Or just counter intuitive? Give me a moment to explain.</p> <p>The story everyone tells goes something like this: Microsoft is strongly entrenched on the PC and in the enterprise. But (XBox and Kinect aside) it’s lost touch with the consumer. <strong>Lose the consumer and you will lose the enterprise</strong>. It’s only a matter of time before iPads displace PCs just as PCs displaced IBM 3270 terminals. Microsoft must respond quickly with consumer-friendly mobile products.</p> <p>I agree for the most part. And I feel terrific about the Windows 8 preview and tablet that Microsoft unveiled at <strong><a href="http://channel9.msdn.com/Events/BUILD/">//build/</a></strong>. Microsoft definitely got some of its mojo back. I’m not just on a “sugar high” as some would have it. Windows 8 is a giant step in the right direction. Regular folks really do like that Metro look. The “developers’ preview” is obviously not as polished as the iPad but there is time before release to perfect the fit and finish.</p> <p>Unfortunately, it won’t be released until December 2012 (give or take). Fifteen months! In a few weeks, after we’ve sobered up, that’s going to feel like forever. Sure, when the grand day finally arrives, we’ll be cheering for the underdog, the version 1.0 Win 8 newbie against the heavyweight 3.0 iPad market leader. </p> <p>Hmmm. Should we be worried about a replay of the Windows Phone adoption debacle?</p> <h3>Lessons from Windows Phone 7</h3> <p>There is nothing seriously wrong with the Windows Phone itself. It’s a joy to use, in some respects superior to the iPhone and in no material respects is it worse. It’s where Metro was born … the same Metro that’s going to wow the tablet market in 2012. Critics loved it … as they love the Windows 8 preview.</p> <p>We can’t fault Microsoft for losing sight of the consumer. The Windows Phone is totally consumer-focused; two years in and we still lack an enterprise story. To make sure we get the point and avoid all possible confusion, Microsoft killed off WP7’s enterprisey predecessor. </p> <p>How is that working out? Microsoft’s share of the phone market has declined steadily and is headed for 1%. Great phone, unwavering consumer focus, pitiful results.</p> <p>“<em>But wait,</em>” they say, “<em>it will all get better with Mango!</em>” Really? Mango is indeed a huge technical improvement. But I don’t understand why that will make a difference in the marketplace. It is not sufficiently different from the iPhone. Seriously, what will I be able to do with a Mango phone that I can’t do with the iPhone? I’m sure you have a list; will anything on that list be enough to change consumer behavior? Will any of it change the foot-dragging behavior of the sales channel? I don’t get it.</p> <p>Look, I completely buy the consumer friendliness bit. The traditional desktop experience doesn’t fly on the phone and it won’t fly on the tablet. The way we write business apps today is totally alienating. So I’m down with the design vision: “Metro good, touch good, square windows bad, icon overload bad, mouse-and-keyboard bad.” </p> <p>The Metro-ish design changes are absolutely necessary … but they aren’t sufficient … because the iPad (like the iPhone) has a commanding lead in these respects. </p> <p>Windows 8 can be super great … and still bomb at the box office. “Great” isn’t good enough. If it were, Apple might have displaced Microsoft on the desktop long ago. The Mac was always prettier and easier to use. Didn’t matter; share never broke 10%. Twenty years and the Mac couldn’t knock Microsoft out of the ring. It was Microsoft’s ring.</p> <p>If “great design” isn’t good enough, what is good enough? What does Microsoft have that Apple lacks? What would make someone choose a Microsoft tablet over an iPad tablet … maybe even put down the iPad and take up a Win 8 device.</p> <h3>Enterprise software</h3> <p>I argue that consumers – not all, but millions of them – would put down their iPads and buy Windows 8 tablets if they had the ability … nay, the ease … of running their existing enterprise applications on that same fun tablet.</p> <p>We consumers aren’t just sitting around watching the Price is Right while stuffing Twinkies into our mouths. Most of us have jobs. Many of us use computers on the job. And while we may season our days with guilty pleasures (“hello, Twitter”), we occasionally get work done.</p> <p>News flash: <strong>people</strong> <strong>take their work home!</strong> Americans especially. <strong>The work we take home is often written for and running on a Microsoft Windows machine</strong>.</p> <p>Why does Microsoft appear to be running away from this obvious fact? Microsoft could … and should make work life – the life bound up in Microsoft-based business applications – a high-profile component of the Win 8 marketing plan. </p> <p>Unfortunately, conventional wisdom says they shouldn’t do that. Conventional wisdom says that mobile devices must cater exclusively to an infantilized consumer.  Little baby consumer want pretty applications that are fast and fluid. Little baby consumer want an RSS reader with big pictures … like this one straight from the Jensen Harris Metro-style keynote:</p> <p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYC-8832HsLclXl3hAlbM_VEhfagnPoNE7DG6y31ylgBVC-r8eMKZTEHYCAavAZjOYAY7a9jYOWfcDL9nUMBSxKTed-HuLZ9iLRbQ3mAaBs9tOw2QLzvs6vvWs8BE2Zngmza3NFsMtlHSQ/s1600-h/image%25255B4%25255D.png"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="image" border="0" alt="image" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj-hFcKzeURQ4qtnZPwoJMBqNr5f_xb1X177B8agIgl2bP_FyQ-m1v-Ocs68VWG3z5Zh8OAwDPIKE7Qj9Ur8xj4netnBF3tRv39qjsj_HFBWWitslABO_iYIpKCAsoSddPIAFvQuWRsw-yJ/?imgmax=800" width="404" height="252" /></a></p> <p>Say what? Geez, who doesn’t need a little pizzaz in his life but call me different: my RSS reader is for <strong><em>reading</em></strong>. Jensen, dude, you’re showing me eight pointless photographs when I want a list of twenty titles and abstracts … you know, something I can use.</p> <p><em>But I digress … </em></p> <p>Where did we get this limiting caricature of the consumer? <strong>I think we bought it from Apple</strong>.</p> <p>Where did Apple get it? Market research? I don’t believe it. I believe Apple made it up. It’s too convenient.</p> <p>Apple has no enterprise play. They couldn’t promote enterprise applications on the iPad because they have no enterprise applications to promote. So they follow the Apple playbook: <em><strong>if we can’t do it, you shouldn’t want to do it</strong></em>. They pretend that mobile is some kind of other worldly, purely personal experience where work does not belong. </p> <p>The sad thing is that Microsoft is falling for it. They fell for it with the phone. They’re poised to fall for it again on the tablet. By slavishly chanting Apple’s mantra, Microsoft effectively disarms itself.</p> <p>Let me be crystal clear.  The tablet is not a PC. Mobile is not the office. Traditional business application UX is tired, clumsy, and unfriendly; todays business apps are as ill-suited for work as they are for play. WIndows 8 Metro is cool beans and a necessary way forward.</p> <p>But its not all about fun and games. <em>Apple owns that market anyway</em>. Microsoft must wrest it away from them. Microsoft can’t win with great design. It can’t win share with advertising. </p> <p>Let me channel today’s consumer for you. I …. don’t … care! Microsoft, I think you’re irrelevant. You’re going to have to rip that iPad out of my hands and compel me to use Windows 8. </p> <p><strong>Convince</strong> <strong>me</strong>, Microsoft, that I can play while I work on that one hot device that covers <strong><em>both</em></strong> my personal life <strong><em>and</em></strong> my job life. <strong>Convince my boss </strong>that the Windows 8 tablet is <strong><em>both</em></strong> a match for the iPad <strong><em>and</em> </strong>a productivity platform for enterprise applications … at no additional cost.</p> <p>Perfect execution of the perfect Windows 8 design won’t move the needle in 2013. By then it will be “<em>me too, too late</em>”.  </p> <p>But enterprise software is the differentiator that Apple can’t match. Exploit that. Don’t let Apple fake you out. Leverage your strength. The enterprise angle must be a strategic element of your consumer play.</p> <p>That’s why I think the Windows 8 “Desktop” stack is the killer feature in Windows 8. Ignore the voices that tell you otherwise. Is “Desktop” too confusing to some consumers? Work on making it less confusing. Don’t kill it; invigorate it. </p> <p>Energize your enterprise developers – hundreds of thousands strong – who want to Metro-ize their business apps. Stop telling them what they can’t do in Metro. Inspire them to build great Metro business apps. Get moving on the roadmap for the <strong><em>enterprise</em></strong> <strong><em>store</em></strong>; get a proto-type out there. Reassure your corporate customers and developers that you mean business by investing meaningfully in the evolution and marketing of the mature technologies they use today. Praise Silverlight 5 and get hopping on Silverlight 6. We aren’t writing business applications in HTML and JavaScript today. We’re not going to have production ready HTML/JS apps in 2012. That’s just jerking us around. If you really don’t think Metro is the answer for all desktop application needs, then paint us a Windows future that is an answer and build us a bridge from here to there.</p> <p>I realize I’m proposing an “<em>and</em>” strategy – consumer apps and business apps - not an “<em>or</em>” strategy. “<em>And</em>” strategies are dangerous because they tend to defocus. You have limited resources to be sure. But you can’t just go to market with a carbon copy of Apple’s strategy. They’ll kill you like they’re killing you on the phone. How many billions will you spend for a few points of share? Redirect a fraction of those billions to <strong>make enterprise software a first class, integrated pillar of your tablet … on day one</strong>. That’s a damn cheap hedge against a repeat of the Windows Phone launch if you ask me.</p> Ward Bellhttp://www.blogger.com/profile/10977457957771020146noreply@blogger.com9tag:blogger.com,1999:blog-393540894130950585.post-7215827705803331862011-09-20T09:09:00.001-07:002011-09-21T11:12:19.422-07:00Metro Business Apps<p>At //build/ we learned that Metro is for content-centric “immersive” apps and Desktop is for data-centric “enterprise” apps. Jensen Harris said it in his <a href="http://channel9.msdn.com/Events/BUILD/BUILD2011/BPS-1004">8 traits of great Metro style apps</a>. Joe Stegman repeated it in his talk, <a href="http://channel9.msdn.com/Events/BUILD/BUILD2011/APP-737T">Metro style apps using XAML: what you need to know</a>. That’s the Microsoft party line and outsiders have been repeating it.</p> <p><strong>Don’t believe it</strong>. The real world doesn’t honor marketing boundaries. Expect to see data-centric applications appear on Win 8 almost from the moment of release.</p> <p>Why am I so sure? Because the same divide has been crossed elsewhere. You’ll find business applications on the iPad today. Is the iPad any friendlier to enterprise apps than Metro? Tell me how … because I don’t see it. I don’t see any way to keep business applications out of Metro.</p> <p>They tell us “Metro is optimized for immersive content-centric apps”. Well Viagra was optimized to treat hypertension. What’s your point? What is more “immersive” than a business application that fills the users screen for hours at a time?</p> <p>I had lunch today with one of our long-time customers. They showed me their iPad port of their <a href="http://www.ideablade.com">DevForce-based</a> Windows Forms desktop application. It’s almost a complete port and they don’t foresee any barrier to finishing the job. </p> <p>It looks remarkably like a typical Windows Forms app: the same gray background, same simple icons, same grids and forms over data, same tabbed interface. They made adjustments of course to accommodate touch and asynchronous server communications. There was no attempt to fancy it up; it doesn’t pretend to be a typical consumer facing iPad app.</p> <p>Customer acceptance has been fantastic … because it does the job in a familiar way. We could talk about UX design all day and it wouldn’t change a thing. The UX app is exactly what users expect. And not just existing customers; the iPad version appears to be driving new sales.</p> <p>What could keep them – or anyone – from porting to Metro WinRT? Three obstacles come to mind.</p> <ol> <li>Must deploy with the Windows Store </li> <li>Metro app certification </li> <li>Paucity of data-centric features </li> </ol> <p>Our customer could leap these hurdles effortlessly.</p> <h3>Windows store deployment</h3> <p>I’m mildly concerned that there is no substantive enterprise deployment story. Ted Dworkin mentions it once in his talk, <a href="http://channel9.msdn.com/Events/BUILD/BUILD2011/APP-121T">Introducing the Windows Store</a>, before returning to the talk’s thesis:</p> <blockquote> <p>We have an enterprise story that supports their unique needs … but fundamentally the Windows store is the only place that Metro-style apps can be acquired. (11:20)</p> </blockquote> <p>I can hardly wait for that “enterprise story”. Big companies simply will not deploy their apps through a Microsoft store. I hope that Microsoft talks sensibly about an acceptable alternative – probably in the form of an enterprise store – within the next six months. I’ll take up this subject in a later post.</p> <p>However, smaller companies may not be inhibited by the lack of private store. Our customer delivers its iPad client as a free app via the Apple store. Anyone could download it … but only their customers actually would. You can’t do anything with it unless you’ve first deployed the companion backend server; you acquire the server and pay for that server separately.</p> <h3>Metro app certification</h3> <p>Apple’s <a href="http://developer.apple.com/library/ios/#documentation/UserExperience/Conceptual/MobileHIG/Introduction/Introduction.html">iOS interface guidelines</a> run over 100 pages. Yet our customer passed Apple’s certification with a Windows Forms UI. Would it pass Win 8 Metro App certification?</p> <p>It wouldn’t pass the Windows Phone certification which dictates fine points of UI style such as application navigation. We don’t have a software certification guide for Metro apps. But we have some clues sprinkled among the //build/ talks and we have the example of applications shipped in the preview.</p> <p>My reading is that the Metro specs would not adversely constrain a business application experience – even if the application looked like a Windows Forms MDI application. I saw rules about screen and image resolutions requirements. I didn’t seen anything that dictated how I use the back button. I can’t have a child window; I can overlay the screen with some something that achieves a modal dialog effect. The keynote on Day 1 demonstrated conversion of Scott Guthrie’s Silverlight business app. I look at the Metro version of Internet Explorer and I know I can write a conforming business application. </p> <h3>Missing data-centric features</h3> <p>The Metro preview and sample applications emphasize content consumption. There are essential input controls such as textboxes, radio buttons, list boxes. But they appear to have forgotten about data grids. </p> <p style="font-style: italic; margin-left: 20px">if you follow this space, you remember that I dislike data grids; I think they’re a design cop out. That’s my opinion, shared by a tiny minority; the rest of you want your data grid … and you should have.</p> <p>The Validation attributes in <em>System.ComponentModel.DataAnnotations</em> are missing as are related interfaces such as <em>IDataErrorInfo</em> and <em>INotifyDataErrorInfo</em>. Apparently, in it’s wisdom, Microsoft thinks that client-side validation of input is unnecessary even for consumer apps. I hope they reconsider before release but we’ve survived without them before and can do so again.</p> <h3>Why would you want to build a Metro Business App?</h3> <p>Metro apps will only run on Windows 8 (and later … if you’re the optimistic sort). I’m guessing Windows 8 won’t release until this summer of 2012. Most companies have not yet or have only recently adopted Windows 7; optimistically, a significant number get to Windows 8 late 2013. Most of us don’t write software today for first deployment in 2013.</p> <p>The Windows 8 tablet is the wild card. If it has the hoped for reception in 2012 it could be a factor in driving Win 8 into the corporation … not as a replacement for existing desktops but as the viral alternative to the Apple iPad. We can dream, right?</p> <p>If the Win 8 tablet is a hit, you’ll want to be on it … and not just in the blue “Desktop” stack. Some reasons:</p> <ul> <li>ARM tablets, with their better battery life, could dominate. Metro apps will run on ARM. Desktop? They will probably only run on power hungry Intel tablets. <br /></li> <li>High performance Metro XAML in native code with GPU acceleration; Desktop XAML is managed code with more limited GPU support. <br /></li> <li>Ready-to-wear Metro Visual Studio templates. <br /></li> <li>Superior touch support and easier access to tablet hardware. <br /></li> <li>Win 8 “contracts” for integration with other Metro apps and cloud services <br /></li> <li>Better cloud integration facilitating “continuous applications” that move application state across devices as the user switches from phone to tablet to desktop. <br /></li> <li>Ride the software platform that Microsoft is promoting and evolving. <br /></li> <li>The “Hotness” factor … don’t discount it! </li> </ul> <p>Those are big draws. Why should I toe the “Desktop for LOB” Microsoft line when I can sneak into Metro and party with the cool kids?</p> <h3>Get ready for Metro</h3> <p>Whoa, cowboy. This is the time to pay attention to Metro … and little more. Right now I wouldn’t take my business application beyond exploratory stage in Metro or WinRT. </p> <p>How would I build production applications? I’d write them in <strong>Silverlight</strong> until the fog clears. I’d write with a <strong>Metro mindset</strong>. I’d isolate anything in Silverlight that isn’t in Metro – hide it behind a service interface - so I’d be prepared to swap out the implementation later.</p> <p style="font-style: italic; margin-left: 20px">See Brian Noyes high-level discussion of what this entails in his post, “<a href="http://www.softinsight.com/bnoyes/2011/09/15/SilverlightDevelopersHaveTheSmoothestRoadToMetro.aspx">Silverlight Developers have the smoothest road to metro.</a>”</p> <p>If I could I’d design all new screens to follow the Metro style guidelines. The Windows Phone 7 Metro style was crossing over to Silverlight design before Build; Win 8 should accelerate that trend.</p> <p>If Metro is as successful in the consumer space as we hope, business applications will be written as Metro apps.</p> <p>Fortuitously, I noticed that <strong>Rocky Lhotka</strong> agrees as he explains in "<a href="http://www.lhotka.net/weblog/WinRTAndBusinessApps.aspx">WinRT and business apps</a>”.</p> Ward Bellhttp://www.blogger.com/profile/10977457957771020146noreply@blogger.com14tag:blogger.com,1999:blog-393540894130950585.post-48395803024525191482011-09-13T13:35:00.001-07:002011-09-13T13:58:06.097-07:00The BUILD Report #1: Sinofsky keynote<p> </p> <p>Here’s my <strong>unedited feed/stream-of-consciousness</strong> from the cheap seats in the arena where Steven Sinofsky is giving his Win8 Keynote. </p> <p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg4v7kFRuSPYssfbpMETELgFAIy3qNp9Z7AnH7EKRMFDWlmFccQ_rXWzXtkH4qMndfLrLtjUgun7YZ-CAwZwE5y_BWHKDGoZYsNjp2Gwx-HkXUZNOumnFgJpBUcuwHfRLZvq_fWkaM0NJ0e/s1600-h/Build%252520Keynote%252520from%252520cheap%252520seats%25255B4%25255D.jpg"><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="Build Keynote from cheap seats" border="0" alt="Build Keynote from cheap seats" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgrAHV3ZGQvqArDVJbylJSb8keEXitb0LGtkZvZllMwK7d0UT9CqSfbxbAXYbZmq3sEm0t90t2G4pMf-Ny29ivDJhT0wMrT_Rt_7XciW7Z1PMrgKrCQAo3fiECptqg-gdgshOi9Wh01z5-S/?imgmax=800" width="362" height="272" /></a></p> <p>Sinovsky opens touting WIn 7 and IE 9 market success to date. </p> <p>Claims touch is so compelling that once you have it on your screen you’ll want on all screens; not my experience in the last year … and that’s not because it doesn’t work. Don’t like leaving the keyboard. As the demos proceed, I start to wonder if I’m going to have to use touch to use Win8. See below</p> <p>Emphasizes that no matter how new Win8 is, everything running on Win7 will run on it. Reiterated throughout the keynote. That’s important to business which must migrate more slowly and a strong contrast with Apple. Means you can be sure the .NET apps you write today will have a good run on the next h/w and OS.</p> <p>Win8 memory footprint and CPU efficiency improves on Win 7 … by a lot. That’s encouraging again for companies with tight capital budgeting.</p> <p>Julie Larson-Green demos. Nice “picture password” = gesture login. No password … just gestures. Sweet. Audience applauds. Twitterverse agrees. Business should like too.</p> <p>The demo is all touch. It’s a little balky but that’s not what concerns me. I’m not sure I want to interact this way. Great for casual user (consumer) but, when you live on a computer, do you want to touch? Maybe I’m freaking out prematurely. It’s not that much different from using a mouse. They recognize my anxiety and reassure us that keyboard and mouse are there for everything. Later, S “I’m a keyboard person” reiterates and demos later (although he does mouse in his demo).</p> <p>The “chrome-free” browser gag went over well. But it really IS nice that the IE browser has no chrome. Very metro … and the cleanliness works (despite the onstage demo struggles).</p> <p>The “fast and fluid” principle is more than fluff. It’s a design principle that makes a genuine difference in comfort. Shown effectively in Julie’s demo.</p> <h2>“How to build” </h2> <p>S: “You pick the language/platform you want to use”. Windows Runtime (WinRT) with client tech (HTML, C++, C#/VB) riding above without privileging any one of them. S. reiterates this point several times throughout, trying to drive that home.</p> <p>The first development demo starts with JavaScript templates in VS. That might make a XAML worrier nervous. But I’m convinced that S means it and that XAML is first class. The port of the Silverlight 2 demo was effective (note to self: what am I to make of a port of Silverlight TWO). This is a big deal to “my people” so I’ll be talking more about that for sure.</p> <p>Metro is the privileged design language … which is a good thing for business app devs as I’ve said elsewhere before.</p> <p> </p> <p>“Windows” javascript api grants access to the OS somehow, as in “Windows.Storage.Pickers.FileOpen …”</p> <p>Big cheers for Blend as an HTML/JS tool. Expected, sure, but it’s still important. The layout ease, the Metro-built-in is nice and productive. Some noise about how this isn’t new in the world. So what. The issues isn’t whether it breaks ground but whether it delivers on the productivity promise. Looks like it will.</p> <p>The write-build-show cycle is crisp.</p> <p>Windows App Store: Store menu in Visual Studio. Built-in licensing model includes trials (but can put your own in). That shows seriousness. They will have a certification process. What about bureaucracy (we know how ugly that is in WP7)? They hope they can allay with (a) a process queue and (b) automated compliance checking tools [big applause for that one]. Now making it easier to find s/w in categories (a problem in today’s WP7 marketplace).</p> <p>The Win App Store is written in HTML/JS. They ballyhooed as a vote-of-confidence in that app technology. Is there a reason it should be HTML/JS? It could only host apps for Windows platform so no x-plat justification. Could have been … should have been? … in Silverlight.</p> <p>So what about deployment of LOB apps in the metro/immersive app environment.</p> <h3>XAML segment</h3> <p>Sinofsky cheer leads. That’s important to dispelling the belief/suspicion that S hates .NET.</p> <p>Nice job of taking an old SL2 Gu app and migrating to Win8 w/o changing the app itself.</p> <p>Then metro-izes by swapping one XAML control for a new Win8 grid control + 2 lines of code-behind + manifest tweak to make it searchable in Win8 => looks metro. Nice. Search and runnable from the dekstop. </p> <p>This deployment is to the NEW Win8 look. In the prior Win8 show, they created fear that would only run in the old Win7 shell. This time, not seeing an old shell. Only showing one shell. AND XAML apps run in it. I couldn’t see any distinction between HTML and XAML app in the shell.</p> <p>Another tweak and it runs in the phone. Very nice. Ok, demo alert, right? It won’t be that easy in reality. That doesn’t diminish the direction; they are putting their back into making XAML apps metro and their deployment easy with tooling.</p> <p>S emphasizes again that Win8 is supportive of your technology choice.</p> <p>The sensor fusion stuff could get you thinking about how tilting the tablet could be used in a bus app UX. It’s easy enough to justify exploring it and using it without fear that you’ve saddled the non-geek dev with incomprehensible, maintenance problem. NFC (near field communication) support makes it easier to write apps that interact with the physical world. POS and field inspection apps come to mind.</p> <h2>Renovated OS tools</h2> <p>Control Panel, Task Manager, PC Reset … just plain nice for developers. Hyper-V in the Windows client.ISO mounting built-in. </p> <p>“Ease of Access” support could matter to those of you who have regulatory requirements affecting your app’s UX.</p> <p>Ink / Touch disambiguation revives pen and the accuracy that comes with it. Take that, Steven Jobs.</p> <p>Windows Live is the backbone of the roaming features with which you propagate settings across devices.</p> <h2>Cloud Integration</h2> <p>Chris Jones talking about Cloud Services. The mail client is HTML/JS … as it should be as it must be x-plat. The app metro design is straight out of WP7 mail app. It certainly is responsive. But have to say that some of the views are clunky.</p> <p>The WP7 hub paradigm is now on Windows Live. People, Photos, Mail. The hub paradigm works; this is a great move.</p> <p>“Every Win8 user has a SkyDrive”. Of course that is great for consumers. But this could be a terrific guarantee for bus. app developers too … assuming that business allows that kind of personalization in the app. When you know that SkyDrive is there, the integration is there, and it’s easy to reach … you can consider making that integral to the app w/o worrying if the user is configured for it … because she always is.</p> <p>I don’t think it’s Drop Box (no auto synchronization), but its great ‘cause it’s in there. Now what about security? I haven’t been that careful with my Live password. Time to get serious. Would need to work on that if I was building Windows Live into my application assumptions.</p> <p>Not available today? The APIs are there today but we’ll have to wait a little for the releases in the cloud … and that’s ok.</p> <h2>The Big Giveaway</h2> <p>Hard to deny the enthusiasm for the Samsung tablet – an Opra moment.</p> <h2>The Mom Factor</h2> <p><a href="http://weblogs.asp.net/dwahlin/" target="_blank">Dan Wahlin</a> told me (I paraphrase) “My mom would love Windows 8 – she would get it – and that’s important to the Microsoft business application developer. The Microsoft platform has to succeed broadly; if the consumer deserts Microsoft, so … ultimately … would business apps.”</p> <p>I agree strongly.</p> <h2>Release Schedule</h2> <p>The “Preview” looks impressive… for a preview. S says “No release date because driven by quality, not the date”. Sure … but I get the feeling it won’t be far off. They’re going wide tonight (8 pm PST) at <a href="http://dev.windows.com" target="_blank">dev.windows.com</a>. No activation. That’s a strong statement because you know how many people are going to write apps on that preview in volume.</p> Ward Bellhttp://www.blogger.com/profile/10977457957771020146noreply@blogger.com2tag:blogger.com,1999:blog-393540894130950585.post-90538858236560598722011-09-13T07:35:00.001-07:002011-09-13T14:16:23.875-07:00The BUILD Report: get it while it’s hot<p>The Microsoft BUILD conference starts tomorrow. My IdeaBlade buddies will be there. I will be there. In a flurry of small posts over the next four days I’ll be reporting on what’s being said officially and unofficially, on stage and in the hallways. I’ll give you immediate reactions and instant analysis from the perspective of the business application developer.</p> <p>I’ll be interviewing many fascinating folks and passing along their insights …I hope with attribution.</p> <p>Clearly I can’t cover everything. And “instant analysis” is … well it’s instant. Enough said?</p> <p>When I get back, catch my breath, and have time to reflect, I’ll try to make sense of it all.</p> <p>Meanwhile,  ride with me, send in your comments and questions, and enjoy.</p> <h2></h2> <h3>Posts in this series:</h3> <h5><a href="http://neverindoubtnet.blogspot.com/2011/09/build-report-1-sinofsky-keynote.html">The BUILD Report #1: Sinofsky keynote</a></h5> Ward Bellhttp://www.blogger.com/profile/10977457957771020146noreply@blogger.com1tag:blogger.com,1999:blog-393540894130950585.post-73371100465281452522011-08-09T21:50:00.001-07:002011-08-09T21:51:57.804-07:00And the (ORM) survey said …<p>In mid-May 2011 I ran a short <a href="https://www.surveymonkey.com/s/EFDevStyle">survey</a> about ORM usage among .NET developers. I wrote a draft of this blog post back then … and forgot to publish it (doh!). I’m finally doing so now in August in hopes that it remains relevant. I don’t know if attitudes have changed (do you?) but what the heck … I might as well …</p> <ul> <li><a href="#Survey">Tell you what the survey asked.</a> </li> <li><a href="#Results">Give you the summary statistics for its two questions.</a> </li> <li>Link you to a <a href="http://www.ideablade.com/wardsblog/ORM_Survey_Results.zip" target="_blank">spreadsheet of individual responses</a>, including comments. </li> <li><a href="#Goals">Describe the survey’s manifest goals.</a> </li> <li><a href="#Design">Discuss the survey design and comments on that design.</a> </li> <li><a href="#Interpretations">Offer my interpretation of the results.</a> </li> </ul> <h2><a name="Survey">The Survey</a></h2> <p>The survey was prepared on and hosted by <a href="https://www.surveymonkey.com">SurveyMonkey</a>, a free/low-cost survey site. It ran from Monday, 9 May, to Wednesday, 18 May, 2011. It consisted of two questions. Here’s question #1:</p> <p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYkkJqFt2xt1At0PtX1SaFdR5xKlwRUSSdVizHOJ1X3BDxMjgldo2r7q_w01CnWhDcgGNlwsc07salP5Xkbg76LdSPUexu8XaC2X7ftM4ayKmqnhzs_Ej2WrHinUsc1mkKpTvnmhaQfTm0/s1600-h/ORM_Survey_q115.png"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="ORM_Survey_q1" border="0" alt="ORM_Survey_q1" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiJmiCUwProRDyytojplfzujZ256fpwgmJiXmo8gg9uR0jHYky-AD-nnE6AaZi4OjRwcXX5EAo1o34Dr1TTUcmNY-i0XeAM0ALfjiZpbSZPFmu0_H8UekMT5371M9sOZHpePWS8ghhO5Hzs/?imgmax=800" /></a></p> <p>If … and only if … you answered “Entity Framework” did you get to see question #2:</p> <p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiQPQGq0rMTJsE4RzRq5wkGGYm5A0HJKqJizUxq1omjTgmFzk6mAm5f7huILnORmNmbbXHc-KmqV58Y6015MAhhifxvzLuZStuM2Y6fNGohdTWgFbounHyvu3uAOELRwp4jaRaPQ5Ls9CiO/s1600-h/ORM_Survey_q24.png"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="ORM_Survey_q2" border="0" alt="ORM_Survey_q2" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh2-faLjHqdksCsAAnNFpoIYFPUtSlCeqgmAZERL16qPrjLPVCf4txzbGdZkKgNOeVSGoUMUtTP24fNbvjRj34019ZvwhqYU9U3nlNBXzmo9egJOzzgS3jpsGYjWCZBL0twuLLQGjCtc4xI/?imgmax=800" /></a></p> <p>The survey permitted only one survey answer per person but you could come back later and revise your answer if you wished.</p> <h2><a name="Results">The Results</a></h2> <p>You can see the survey <a href="https://www.surveymonkey.com/sr.aspx?sm=bgyJ4ipGXAiTAf2W09hoyLuice_2fMprLdjvnulk2Icyc_3d" target="_blank">results on the SurveyMonkey website</a>.</p> <p>I downloaded all 896 individual responses as of May 18 into <a href="http://www.ideablade.com/wardsblog/ORM_Survey_Results.zip">an Excel spreadsheet</a>.The spreadsheet is useful if you want to correlate comments with question answers. The comments can be entertaining.</p> <p>Here’s a picture of the statistics as displayed in the spreadsheet:</p> <p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjI4Va-kTzxDpL6awdw1A6PGyW1oHqs46AmMWgnVAsEw-9N0vlTGhfcp-_b3ZF2PRwBbM5t1CSn0WRRn6_fSaxVq3HSfMGIY4CZW-3-k1Ge534oj_c2ehyWap1mzt3GFuOQ0TZqxi0Ib_l6/s1600-h/ORM_Survey_stats4.png"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="ORM_Survey_stats" border="0" alt="ORM_Survey_stats" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEicKMmzl-XW_kDgPWf5GliqEnhZ7-3HsbCZe-QLMyZms4ik7I2cp9quxekcNUrnQGObkupr-Z9Vl7USQeOA6vYATt1PT-3RWuPee6Nn2NaBcoiWb8eTptbxrcYa8Tm5_nJXgFXT6kIP2LH8/?imgmax=800" width="528" height="581" /></a></p> <h2><a name="Goals">Survey Goals</a></h2> The survey seeks insight into how developers of .NET data-driven applications prefer to manage their data. More specifically: <ol> <li>Would they use an <a href="http://en.wikipedia.org/wiki/Object-relational_mapping" target="_blank">ORM</a></a> … or not. <br /></li> <li>If they would use an ORM, would they use Microsoft’s <a href="http://en.wikipedia.org/wiki/ADO.NET_Entity_Framework" target="_blank">Entity Framework</a>; the popular, open source <a href="http://en.wikipedia.org/wiki/NHibernate" target="_blank">NHibernate</a>; or some other ORM tool. <br /></li> <li>If they would use Entity Framework (EF), which style would they use to develop their entity models. As of version 4.1, EF offers three styles called “Database First”, “Model First”, and “Code First”. <br /> <br />For you readers who don’t know what those styles are, I recommend Julie Lerman’s <a href="http://thedatafarm.com/blog/data-access/model-first-database-first-or-code-first-ndash-update-to-data-points-column/" target="_blank">summary of these styles</a> (she calls them “workflows”) and her <a href="http://msdn.microsoft.com/en-us/magazine/hh148150.aspx" target="_blank">May 2011 MSDN article</a> on the subject. </li> </ol> <p>I wanted developers to respond as if they were: </p> <ul> <li>building an application with a medium to large model </li> <li>free to choose the data modeling/access technology </li> <li>required to work with an existing relational database of many tables, filled with irreplaceable production data. </li> </ul> <h2><a name="Design">Survey Design</a></h2> <p>In this section I talk about how the questions were formed, how I found the respondents, and survey bias.</p> <h3>The questions</h3> <p>The survey only had two questions – and you couldn’t reach the second question unless you answered “Entity Framework” to the first. I was adamant about keeping it short. I hate long surveys and assume others do too. </p> <p>I really wanted to ask demographic questions. I wanted to know about respondent backgrounds, what kinds of apps they built in which client technologies for what kinds of customers. Were they architects, trainers, or practitioners? Were they actually committed to building with the selected technologies or only hoping to do so or merely advising others to do so?</p> <p>I backed off mostly because it would have bulked up the survey but also because I had no hypotheses at that time that required demographic information. As a general rule flailing away with pointless questions invites spurious correlations. If the survey results suggest new hypotheses, someone can pursue them independently.</p> <p>Some folks were miffed that they couldn’t answer the EF development style question unless they intended to use EF. Sorry … sort of. Question #2 is about how<strong> <em>EF people</em></strong> would use EF. How an NHibernate person would develop an NHibernate model is interesting but out-of-scope. Moreover, I didn’t want to muddy the interpretation with advice to EF developers from people who wouldn’t use EF. The second question is not a vote on best practices or preferred technologies; it’s trying to surface the practices that EF people intend to use.</p> <p>A number of respondents want to pick more than one answer. They wanted checkboxes instead of radio buttons. Sorry but you’ll have to come up with your own survey. I deliberately forced you to choose … as you would have to choose when faced with one application to build. You were not granted the consultant’s luxury of saying “it depends”. I left you room to vacillate in the comments.</p> <p>I have one regret about question #2. I failed to make clear that the “100+ table, RDB application” context that I described in question #1 <em>should apply to question #2 as well</em>. That was my intention. I didn’t say so in the phrasing of the question; it is clear from some of the comments that many respondents weren’t sure about this. I’ll never know the degree to which that uncertainty skewed the results. </p> <p>I’m going to do the only responsible thing and blame my survey reviewers for failing to raise the alarm before I launched the survey; shame on you guys!</p> <h3>The Sample</h3> <p>The sample is far from “scientific”. I did not ask an independent, qualified research group to identify and survey an unbiased sample. I simply announced the survey on Twitter on May 9th. I asked everyone I could think of to re-tweet it; many of them did. I learned that IdeaBlade announced it on the DevForce forum but no one, to my knowledge, sent email to any of our lists. I figure if you answered the survey, you learned about it on Twitter. Which means you probably follow me or follow someone who follows me.</p> <p>It’s reasonable to suppose that we have interests, opinions, and experiences in common. We are in none of these respects the norm for the general .NET developer population. Accordingly, I’m reluctant to apply my interpretation to that broader population. Well … kind of reluctant.</p> <p>Frankly, I am too cheap to do it properly. While I think the survey questions are defensible, I’ll concede that the sampling technique is not … and introduces a significant bias of some sort. Of what sort? I take that up next.</p> <h3>Survey Bias</h3> <p>Many of you took me to task on my approach to sampling … and we’re free with your conclusions about how that would bias the results. My secret pleasure in this is that you had so many different and conflicting notions about what that bias would be. </p> <p>Some were sure that it biased the survey toward EF. Some said it biased the survey against CQRS and NoSQL. Some said it biased the survey against native ADO approaches. Some said it biased the survey in favor of egghead pontificators who have no practical experience.</p> <p>Some people see a bias in the survey’s <strong><em>goals</em></strong>. I suppose there is an existential “bias” in one’s research interests. I’m please to ponder the significance of wanting to know one thing versus another. Don’t stop there; ask me why I’m running a survey about ORMs instead of world peace.</p> <p>I’m more concerned about survey bias. What factors in the questions, the sampled population, the conduct of the survey, and the interpretation of results that undermines the survey’s avowed research goals?  I’m sure there are plenty of such factors. I’m not sure where they point.</p> <p>I was twice accused of <a href="http://en.wikipedia.org/wiki/Confirmation_bias" target="_blank">confirmation bias</a>, which in brief means “a tendency for people to favor information that confirms their preconceptions or hypotheses regardless of whether the information is true.”  I’d be more susceptible to this charge if I had preconceptions to confirm. Take question #2 for example. I don’t have a theory about which EF development style people will prefer. I guessed that “Code First” would win about 10% of the votes, not 42%. But I was no more invested in the outcome than I am when guessing the number of jelly beans in a jar.</p> <p>Question #1 is a more delicate matter. My company placed a bet several years ago that EF would eventually dominate the .NET ORM space. Around 66% of survey respondents favored EF; NHibernate was a distant second at 18%. This outcome is certainly consistent with my expectations. Is that evidence of “confirmation bias”? You can’t call a survey “biased” simply because the results seem to favor the author’s prediction. You have to explain how the question or the conduct of the survey favored EF. I don’t understand how that could be in this case. The question seems innocuous to me. And while my twitter-verse is indeed ORM friendly, it is not pre-disposed for or against EF; I’ve got a ton of EF-hating friends.</p> <p>So you still think my audience tilts towards EF? Maybe it does. But is it significant? The gap between the EF preference (62%) and the preference for all other ORMs (18%) is 44%. How do you explain that?</p> <h3>Bias toward ORM uses</h3> <p>As I see it, the gravest potential for misinterpretation would be the misguided assumption that most developers know about, care about, or use ORMs.</p> <p>People reading this blog as well as people who took the survey are acquainted with ORMs. We either use one or have used one. We like them or we hate them. Remember, only 7% of respondents said they wouldn’t use an ORM</p> <p>The sample must be severely skewed if only 7% say they won’t use an ORM. I know that <strong>the majority of developers in the general population don’t use an ORM</strong>. How do I know ? OK … I don’t have hard facts. But I have strong anecdotal evidence. Most of our customers and prospects have never used an ORM before. I’ve been to a lot of user group meetings and, based on a show of hands … on several occasions …, a tiny few of the attendees know squat about ORM.</p> <p>We have to be careful in our interpretation of this survey. We can’t say much about developers in general. We might have gleaned something useful about developers who use ORMs.</p> <h2><a name="Interpretations">Interpreting the Results</a></h2> <p>I wasn’t surprised by EF’s dominance … as I noted above. It seems EF v.4 is finally over the bad press that greeted v.1 and is begrudgingly accepted as “viable” even by staunch NH supporters.</p> <p>I was surprised at the affection for Code First. Few could yet have tried it. Evidently it taps into some disaffection with the “database first” workflow and its visual designer. People I deeply respect have tried it a few times and they like it a lot. They haven’t built anything significant with it yet … but what they like about it resonates strongly with me. I’ll have more to say in a future post.</p> <p>On the other hand, “database first” has ardent fans (read the comments). It’s the majority choice and will remain so as long as most developers who conceive of their applications primarily in terms of the data they store. Database management tooling is capable and the practice of simultaneously evolving schema and code is entrenched.</p> <p>I’ve tried both “database first” and “code first” development. There isn’t an obvious productivity winner. One could pick a side on other grounds, but only a clear productivity edge will shift the balance among active developers.</p> <p>So it looks like “Code First” will have a strong following much sooner than I expected. But it won’t hurt “Database First” which will remain the popular choice.</p> <h2><a name="Intentions">My Commercial Agenda</a></h2> <p>I’m a curious guy … but I don’t run surveys for the fun of it. The survey was honest but it wasn’t innocent.</p> <p>Consider the survey’s framing context: an application built to accommodate a 100-table existing database. My company, <a href="http://www.ideablade.com" target="_blank">IdeaBlade</a>, makes and sells a product called <strong>DevForce</strong>. DevForce helps you build data-driven, Rich Internet Applications. Our sweet spot is the customer who intends to migrate an existing Line-of-Business (LOB) application to Silverlight or WPF. The existing data store is almost always a relational database. </p> <p>This customer is torn about how to get there. He’s acknowledged that the application will have to be rewritten back-to-front … which opens the door to a new data access architecture. But he’s not completely free to start from scratch. He has an existing business to run with real customers and real data. He’ll have to maintain the existing application while building its eventual replacement. He is naturally reluctant to rip out the database or even restructure it. I wanted the survey to elicit responses from professional developers facing a comparable situation. </p> <h3>EF First</h3> <p>The attention to Entity Framework is no coincidence either. DevForce is not an ORM and can work with any source of data; our value really kicks in after you’ve defined your entities and figured out how you will persist them.</p> <p>But DevForce is cozy with the Entity Framework. Close alignment with EF was a <strong><em>business decision</em></strong>, not a technology judgment. It has worked out well for us and our customers. The survey results indicate that we made a sound choice … and shouldn’t bother integrating with NHibernate or another ORM; the commercial demand is simply not there.</p> <p>You may feel differently. You’re not selling an infrastructure product. You may have good technical reasons to prefer a different ORM. I suggest, however, that you factor industry trends into your decision.</p> <h3>Code First</h3> <p>We really wanted to assess the appetite for the new EF “Code First” style. DevForce currently favors the “Database First” and “Model First” styles. We extend the EDM with our own attributes, the EDM Designer with our own properties, and we can generate our own classes from the conceptual model’s XML. </p> <p>Should we stick with those workflows or add support for “Code First”? We suspected that “Code First” would attract an audience. We weren’t sure how big or when. </p> <p>The survey tells us it’s going to be big soon; nearly 42% of EF respondents chose “Code First” as their preferred style, just 5 points below “Database First”. So we’re hustling on our Code First support. We just released the first preview which gets us more than half way home. You can <a href="http://drc.ideablade.com/xwiki/bin/view/Documentation/code-first">read about it here</a> and I'll have more to say in future blog posts.</p> <p>Got an opinion? I want to hear it.</p> Ward Bellhttp://www.blogger.com/profile/10977457957771020146noreply@blogger.com1tag:blogger.com,1999:blog-393540894130950585.post-56613005603432752152011-07-01T16:21:00.001-07:002011-07-08T18:20:59.183-07:00Read “Win 8-Longhorn Dream Reborn”<p>Unless you’ve been taking a long and much needed vacation in the woods, you’ve heard something about Windows 8, Microsoft’s promotion of HTML5, and it’s coy silence about the future of .NET.  You are <a href="http://arstechnica.com/microsoft/news/2011/06/html5-centric-windows-8-leaves-microsoft-developers-horrified.ars" target="_blank">probably a little spooked</a> if you’ve committed some part of yourself, your product, or your company to WPF or Silverlight. Does anyone know what is <em>really</em> going on?</p> <p>I have no revelations for you. I wouldn’t be allowed to blog about revelations if I had them. I don’t have anything fresh to say either. I do have opinions ... details of which must await a future post.<p>In summary until then ... I’m not worried. While we at IdeaBlade are exploring what it means to have a DevForce JavaScript client, no one should mistake that interest for wavering in our commitment to .NET. We are confident that XAML clients will thrive for a long time to come.</p> <p>Of course that’s what <strong><em>we</em></strong> think. Microsoft has done a fabulous job of creating uncertainty about the future of Silverlight and .NET. I’ve had plenty of conversations with colleagues and customers who are paralyzed by doubt. Frankly, that’s not good for our business. I don’t think its good for <strong><em>your</em></strong> business either. Perhaps you can afford to wait … and wait … for some magic moment of clarity. Will we know more in three months at the <a href="http://www.buildwindows.com/" target="_blank">BUILD conference</a>? Sure … although if I’m certain of anything it is that Microsoft will keep the mixed messages coming. </p> <p>You have to make a decision at some point based on the best information available. To that end, I direct your attention to a highly-regarded, week-old article in <em><strong>ars technica</strong></em> by Peter Bright: “<a href="http://arstechnica.com/microsoft/news/2011/06/windows-8-for-software-developers-the-longhorn-dream-reborn.ars" target="_blank"><font size="3">Windows 8 for software developers: the Longhorn dream reborn?</font></a>” It’s well-written, well-reasoned, and grounded in a bit more than opinion and rumor … as in the author is talking about what’s actually in some of the early bits.</p> <p>I’ve read it over a few hundred times and … honestly … it still seems right to me … right down to it’s stirring conclusion:</p> <blockquote> <p><strong><em><font color="#4f81bd" size="4">Far from being a developer disaster, Windows 8 should be a huge leap forward: a release that threatens to make development a pleasure for native, managed, and Web developers alike.</font></em></strong></p> </blockquote> <p>Here are my favorite excerpts:</p> <ul> <li>Windows 8 will ship with a pair of runtimes; a new .NET runtime and a native code C++ runtime. <br /></li> <li>There will be a new native user interface library, DirectUI <br /></li> <li>A new version of Silverlight (v.6? codenamed Jupiter?) will run on top of DirectUI <br /></li> <li>DirectUI is built around a core subset of current WPF/Silverlight technology and includes support for XAML. <br /></li> <li>This core will give C++ programs their modern user interface toolkit and, at its heart, it will be the same toolkit that .NET developers use too. <br /></li> <li>XAML and the WPF-like, Silverlight-like way of developing GUIs are going to be absolutely central to Windows development in the future. <br /></li> <li>It gives parity to native C++ and managed .NET code. Instead of being separate, each with its own different capabilities and strengths, they will be peers. <br /></li> <li>Want to write an immersive application in native C++? That's cool. Want to use C# and Silverlight? That's cool too. Both will be supported. Far from being left behind on the legacy desktop—which was the impression that many took from the presentation—native C++ and managed C# will both be first-class, supported ways of developing immersive, touch-first, tablet-friendly Windows 8-style applications. <br /></li> <li>HTML5 and JavaScript will be an option too [with] greater access to operating system functionality than regular webpages … Feature-wise, they should be at the same level as .NET and native programs. It's just that they'll use an HTML5 programming model and JavaScript. </li> </ul> <p>Wouldn’t it be great if Microsoft came out and said this? Or said anything?</p> <p>They won’t … not until their <a href="http://www.buildwindows.com/" target="_blank">BUILD conference in Anaheim in September</a>. Microsoft isn’t deaf. They know all about developer anxiety on this score and have decided to do nothing to allay that anxiety.</p> <p>Fine. Be that way. Meanwhile, those of us who have work to do are wise to keep moving along the .NET client track.</p><h3>Related Articles</h3><p>A David Burela post, "<a href="http://davidburela.wordpress.com/2011/06/14/premature-cries-of-silverlight-wpf-skill-loss-windows-8-supports-all-programming-models/" target="_blank">Premature cries of Silverlight / WPF skill loss. Windows 8 supports all programming models</a>", offers a wealth of detail extracted from the Windows 8 Milestone 3 leak, all consistent with the <b>ars technica</b> article.</p>On July 6, InfoWorld published their take on these matters in "<a href="http://www.infoworld.com/d/application-development/the-fall-and-rise-microsoft-silverlight-163" target="_blank">The fall and rise of Microsoft Silverlight</a>"<p style="margin-left:20px"><i>Silverlight found a foothold in Windows Phone and has more recently emerged as a key component of the Jupiter application framework and programming model for Windows 8. If Silverlight has become less important as a rich Internet application (RIA) framework, it has become more important to Microsoft's desktop and mobile platforms overall.</i></p><p>Again, it's more tea-leaf reading than hard news ... but it reflects the emerging consensus that .NET and XAML clients remain at the forefront of Microsoft development technologies.<p>Stephen Forte of Telerik <a href="http://www.stephenforte.net/PermaLink,guid,8b91d036-01b1-4a3e-9391-615eb801b969.aspx" target="_blank">posted his musings</a> on the future of XAML clients. Noteworthy to me is what Telerik is actually <b>doing about it</b>:<p style="margin-left:20px"><i>I don't see Silverlight as being dead, but rather reborn bigger and better. Instead of being its funeral, the Build Conference will be Silverlight and XAML's graduation party. At Telerik, we are also going to double down on our XAML strategy. ... We see Native XAML as a massive opportunity and will continue to support our XAML tools now and in the future.</i></p><p>That's putting serious money where their mouth is. Why not you?</p>Ward Bellhttp://www.blogger.com/profile/10977457957771020146noreply@blogger.com3