Visual Studio LIVE! Orlando 2013 Day 2

Visual Studio Live! Keynote: The Transformation of Software Development and Application Lifecycle
Kris Lankford, Senior Product Manager, Microsoft

The keynote today was proceeded by Rocky Lhotka sneaking in a few words about the sponsors and doing a few informal pools. I'm not a perfect judge of audience size, but there has to be 300-500 people, and he asked about the general audiences main role in development and the results were interesting. Some people (including myself) raised their hand more than once obviously not pigeonholed to a single technology:

ASP.NET: 85%
SPAs: 15%
WPF: 10%
WinForms: 15%
WinRT: 0% (I didn't see 1 hand)
iOS apps and Android: 5%
Azure: 5%
VS.NET 2012: 95%
VS.NET 2013: 60%
TFS on premise: 60%
TFS in the cloud: 10%
Windows Phone: 5% max
iOS phones: 20%
Android phones: 75%
People without a smart phone: (2 people)
People with less than 3 devices: (laptop, tablet, smart phone, etc.) 0%

Once Kris began to present he kicked it off with a look through technology over the recent years. 90's Windows and the PC, 00's Internet emergency, and 10's is being considered the 'mobile' generation, To this end the Cloud is essential to bring together all of the devices and the 'modern app' strategy. 

The cloud provided additional scalibility and availability of services required for the mobile world and mobile development. In fact VS.NET Online provides cloud based life cycle management with the fastest way to provide product updates.

The evolution to the new mobile world could take multiple forms. As Kris presented 'Do nothing' Start from Scratch', 'Embrace the Cloud' are 3 approaches to modern app development. The combination of Visual Studio, SQL Server, and Windows Azure provide the tools necessary to deliver mobile applications.

I'm excited to learn more about the partnership between Xamarin and Visual Studio. Xamarin (from the creators of mono) to provide cross platform mobile applications via a single code base (iOS, Android, Win Phone, etc.). There are Xamarin simship benefits available to MSDN subscribers with VS.NET 2013.

When speaking about the cloud and a use case from a company named Flavours, some metrics were pulled about the ability to scale in the cloud. This particular company issues tickets and was able to increase the number of tickets issued many times over by the ability to scale resources. The overall point is anyone concerned about cloud based deliver and things like speed or efficiency need not worry. Of course I'm sure there is a price tag associated with scaling in the cloud (add some CPU power and servers Azure!), but the ability to have high performant cloud based solutions is absolutely feasible. The 'pay as you go' model helps keep the economics of this in check.

Being that Kris is from Microsoft, I enjoy hearing information straight from the horses mouth. The desire to deliver tooling (i.e. VS.NET 2013) not just to 'update' an IDE but have the motive of helping us develop applications faster is good to hear. The 'adaptability' of the tool to do 'agile your way' is nice. I must mention that the tool set seems really in line with teams running an agile shop assisting with features for sprints, backlogs, and release management.

To expand on Visual Studio Online (formerly TFS Online), Kris spoke to the lightweight editor available named 'Monaco' that complements the current editor and is targeted for Azure based applications. There was a 'Website from Gallery' template that offered a plethora of different options (i.e. Wordpress, etc.) to quickly create and deploy a website. Between this and Azure I'd gather with less than a dozen clicks one could have a website deployed to the cloud.

Microsoft obviously has some fantastic tooling available to get us moving into modern app development that leverages the cloud. I think based on feedback via the informal pools, most of us are a few years behind the cutting edge development and need a little time to ingest. It doesn't mean this type (cloud) development is not taking place because it most certainly does (downloaded or used any mobile apps or used any cloud based solutions lately? of course), but I'm sure running at the world of the 'common busniess' many are still doing MVC and similar development. I'm excited about the new technology and tooling and will make sure to get some more information on these topics as the week progresses.

Visual Studio Live! Keynote: The Transformation of Software Development and Application Lifecycle
Rocky Lhotka, CTO, Magenic

The 1st session today is with Rocky Lhotka who has to be in the top 3 presenters I've ever been in attendance for at a conference, so I'm very much looking forward to this session. He can engage and interact with an audience probably better than anyone which makes the sessions extremely interactive and interesting.

I love it, Rocky States "I'm always hesitant to say 'Modern' apps. Does that mean 5 years from now we will be doing 'Post Modern Apps' ". For now we'll stick with with the terminology, and figure out the branding 5 years from now :P For today's definition a 'Modern App' is on that is mobile, cross platform, and cloud based. As mentioned in the keynote, we will attempt to answer the question of how far a product like Xamarin will take us to stick to a single code base for cross platform delivery. Xamarin compiles C# to run natively on the platforms outside of Windows (Android, iOS, etc.)

Some time was speaking about 'inflection points'; change in direction or shift in direction with technology. VB6 to .NET was not necessarily a true inflection point because a WinForms app built in C#, VB.NET or even VB6 was something the end user was unaware of when running in the application. However today the influx of tablets, smart phones, etc. is presenting a true inflection point. The inflection point now is, we can't tell where we will be in 5 years which is not the way it has been in the past. WinRT, Java for Android, Objective C for iOS, JavaScript for all, nobody knows. 

There was also a conversation about the end of 'Moore's Law'. Think about this example: a top of the line laptop 3 years ago specd' out contains an i7, 8GB RAM, etc. Top of the line laptop today specd' out would be much the same: i7, same memory, SSD, etc. Hardware is just not doubling at the speed it used to.

Consumers vs. Enterprises. Consumers are the cutting edge, enterprises are not. Consumers want swipe ability, bright color, interaction, etc. Enterprises move at a slower pace - folks will move to Win8 after SP2 or SP3, finally get off of XP, continue to use 'crusty' WinForm apps, etc.. Since most of us are developing for the latter and fewer for these 'type A' cutting edge companies, there will be a bit of the rubber band affect with the new technology and roll out. Microsoft is finally realizing that enterprise licensing is their lions share of sales, so it's not a good idea to alienate developers in that camp.

The main list of client platforms right now are iOS, Android, and Windows. Each have their strength and weaknesses. However Windows has a leg up because it's the only platform that goes from mobile to the desktop via Windows 8, and Windows still has +90% of the market share in the busniess world across the world. It is naive to think that Windows can't compete in this market; a company that size with it's massive amount of resources are absolutely a key player. As Rocky stated, it might even be 'their game to loose.' In an informal poll, nobody knew which would be dominant in 5 years. His best guess was he still had hopes for Windows being the dominant force if they fix the WinRT model. They could still screw it up, as he thinks they were intent on doing previously, but it seems staged the best for the future.

The server futures most likely resides in the cloud. Currently, most of our data is with Amazon, Google, or Windows (Azure) servers. Since Scott Guthrie got involved/began leading Azure a few years ago, popularity has increased greatly. 

A great example was made about the ease of using Azure via the question "How long at work does it take to set up a new test server?" Odds are a very long time and it typically costs a lot of money. With Azure this can be done in under 10 minutes. Yes impressive, and the sessions I've seen from Scott Guthrie have sold me well on the platform and it's ease of use. The reality is the enterprise still doesn't trust placing data and especially sensitive data in the cloud.

The main cloud computing models are the following: Software as a Service (gmail, Salesforce.com, Outlook), Platform as a Service (entire platform as services), and Infrastructure as a service (Rackspace, Azure, etc.).

I really enjoyed the overview of the architecture and layering used for the 'MyVote' App that will be reused throughout the Modern Apps Live sessions. A combination of Rocky's CSLA.NET for reusable Business Logic, along with Xamarin to go cross platform. Take a look at the number of platforms using the same guts underneath. I live for this kind of stuff as an architect myself. The 'Data Portal' block below will be Azure for the sessions, but just as well could be IIS (image courtesy of Visual Studio LIVE! and Rocky Lhotka).

One question I did get in at the end was the hesitancy of companies to move their data or have it pass through the cloud. Most companies are afraid to have their data leave their 4 walls. I brought up sensitive data like HIPPA or the like. Rocky validated some of these concerns and did state that you cannot place HIPPA data in Azure because the databases are not HIPPA compliant which makes placing data in them illegal. However, as to the cloud being 'less secure,' Microsoft and Amazon can hire the best security experts in the world. Do you think you have better experts managing your infrastructure? The answer is more than likely 'No.

What's New in the .NET 4.5 BCL
Jason Bock, Practice Lead, Magenic

I always enjoy Jason's talks as he has an amazing amount of deep and low level .NET knowledge to share. Wouldn't surprise me if he was ever offered a job on the GC team or something for Microsoft because he really knows his stuff well.

The BCL (Base Class Library) can be seen in reference to the other .NET components in the diagram below (image courtesy of Visual Studio LIVE! and Jason Bock):

One of the challenges is to determine what's different in the BCL and .NET Framework each time it is released. Jason had built a small tool that will get the binaries for the framework and then make a comparison. his had worked for years until .NET 4.5 which was considered an in-place update (same as 4.5.1). There is no new directory in Windows and the 4.0 directory is reused and overwritten. 4.5 and 4.5.1 are a superset of the APIs in 4.0, so you can obviously still target older frameworks as before. The solution to making a comparison for the purpose of the tool is to copy everything from the previous framework into a separate location to stage for comparison. The net result is to truly determine the differences in frameworks. The code for this tool can be found at: http://www.jasonbock.net/JB/Code/

There were a few dark corners of the framework that were obsoleted in 4.5, but Jason had never even heard of the obsoleted. Point is there is a 99.99% chance you will not be affected by the changes. Some of the cool additions to the 4.0 framework (for those still catching up) are Lazy<T>, String.IsNullOrWhiteSpace(), System.Runtime.Caching, Tuples, and Concurrent Collections.

Next up was a conversation on concurrent programming. Terms like deadlocks and race conditions when doing multithreaded programming are fading away to the past and being taken over by newer methods that encapsulate this challenges into an abstraction that is easier to program against. Because processor speed is not increasing, but the number of CPU cores is, it would behoove us to leverage the additional cores when possible. In fact the suggestion was made to not create threads manually anymore; one should be using Tasks via Task or Task<T>.

An example of using a StreamWriter to output 10 guids to a file was used to display the progression from synchronous to asynchronous solutions. When the demo using Tasks was presented, Jason highlighted if you don't wait for the Tasks via 'Wait()' or 'WaitAll()' will cause unexpected or undesired behavior. Essentially if you don't wait on the Task, code will continue to execute after the 'async' method is called and the Task returned may not be able to be used properly.

Async and Await cam along in .NET 4.5 (I have a blog post in 'draft' form for months now I need to finish on this topic) to further ease the async development. I still get a tad confused on async and await because decorating the method with async and using await does not make it truly async (I get this part). It's the part of using the await which is blocking. If we have to await our tasks it makes essentially synchronous code. One way to extend the async nature is to return a Task from the async method, continue working, and then await for the Task at the last possible safe spot.

There were some cool new Caller Information Attributes built in as a part of reflection in 4.5.1 in the following: [CallerFilePath], [CallerLineNumber], and [CallerMemberName]. Add these attributes and either supply values or use what they produce to get some tracing information at compile time. He emphasized compile time because of the use of Reflection.

The next example used 10000 loops and allocated 10000 bytes to show memory allocation. The memory was gobbled up as expected and used 102mb. Using the 'WeakEventManager' and 'WeakEventHandler' will create  a weak reference which allows us to recapture resources much easier. The net result after re-running the example was a use of 4mb. Yes that's impressive. I didn't even peak at the slides and Jason got into the GC and some of it's particulars as I prefaced this sessions entry; really smart low level .NET guy so I recommend to follow him on Twitter and check out his newest book Metaprogramming in .NET (just recently translated into Japanese as I understand as well - so the world is craving Jason's knowledge!)

To list off some of the really other cool features added in 4.5 here is a short list: zip compressions, web sockets, bundling and minifying for ASP.NET, UDP in WCF, System,Identity, System.Json, and the Ribbon Bar in WPF (only 5 years behind). In 4.5.1 'edit and continue' functionality for 64-bit apps is also available.

Modern App Design
Billy Hollis, Practice Lead, Next Version Systems

In my office at work I have 3-4 books I bought to bend my mind on designing application from a UI / Visual aspect. The progress through these books has been lackluster I admit, but like every thing else I'm waiting for that 'day' when I can get everything in my backlog completed :P. I have a craving for thinking outside of the box on design and doing things in a more modern fashion, so I find myself here today.

There are some predators in the 'Microsoft Ecosystem', namely iOS and Android. There is a roughly 80% usage of a iOS devices with executives in companies. Even though from the informal pools taken at the beginning of the day, you need to be ready and flexible for cross platform development or become irrelevant.

Billy showed this nasty WinForm picture with what looked like 100 controls on it. I'm thinking, how did he get that app I wrote??  :P 

Modern apps break parts down and actually use touch in a way that isn't just using touch to emulate mouse clicks. We need to think about design differently. Understanding the fundamentals of the design process must be understood. Billy even states he doesn't believe Microsoft even gets this process.

FANTASTIC example given about the way we 'developers' think. Question: "How many developers have been called into a meeting to listen to requirements on a new system?" Almost everyone. "How many stop listening after 5 minutes stop listening and begin coding the solution in thier brain?" More than half the folks admitted to this. We as developers need to learn to listen better to become better designers and move past our code addiction.

'The wall of data grids design' was a phrase termed about the hurdle to slap a ton of DataGrids all over the screen. This design was made for mouse and keyboard applications, but not at all for touch screen and smaller screen smart devices. Have you ever tried to pull up a large data grid on a 4" screen? I know I have and it's awful. However getting users and management to move away from DataGrids and that mentality is not easy to change. 

One example of design he brought up that peaked my ears was about using birth dates in the medical world. For years the apps he has designed they no longer put the birth date on the scree for the doctors. They don't want to know a date, but rather a person is 41 years old or even 4 days old. He also demonstrated a WPF application using badges in the form of smiley faces to give instant recognition of a customers sentiment. This method is much more effective than digging through grids for textual data. In the web world HTML5 offers a rich ability to design applications conducive to a modern design.

Interesting because one of the attendees stated that the 'modern' version of an app Billy showed was using a DataGrid. There are no DataGrids in Windows 8 actually. It was a stackable list panel control and it was a much improved design. So the design doesn't mean you can't list out repeated information; it just is designed in a more natural way.

The problem with DataGrids is they require the brain to scan and decipher information. This is not as quick and efficient as other design methodologies that use visual queues. It's interesting because this discussion had a hint or artistic creativity. Minimalism is popular right now and the brain is tailored well to visually interpret simple designs. Think of the new Windows home in Windows 8 and the tiles - very simple.

Irony is, users like white space and clean software. The more complex a screen or app design, it raises the stress level. An analogy was made to a picture of the beach; why does it reduce stress? Simplicity. 'Horror vacui' is the fear of empty space. Overdoing it is a bad idea in software design. I brought up that he wouldn't like the 'eTrade' app on a commercial I saw on TV. It didn't have 1mm of free space. I asked if for an app like that presenting massive amounts of data was acceptable. His answer: 'No', there is always a better alternative.

Billy advocates for an experimental and collaborative design process. It should be as rudimentary as pencil and paper (story boarding) even over a wire framing tool. It needs to be iterative and allow changes quickly which a simple pencil and paper will yield. During the design process we need to listen and observe users in their real work space. Don't try to design a modern application without observing the user.

Those who transition to modern apps must let go of the past and accept massive amounts of design changes. Making small changes to existing processes is not a solution to the modern design techniques. To this end making a single prototype is also a bad idea. There should be multiple competing designs that the user can select from. One advantage to high level designs is the reduction of the 'move 3 pixels left' problem by being able to vet out a better design up front through the design competition and selection process.

"Be bold when you do Modern Apps." 

Check out Billy's site for a nice checklist for the design process. Billy is also available to be brought into a company to train teams on design.

Unit and Integration Testing of Modern Apps
Jason Bock, Practice Lead, Magenic

For those of us that ride motorcycles and are not pretentious about a particular brand (yes you know who you are), the consensus is any riding at all on any type of bike is better than not riding.

I think this philosophy initially can be applied to unit testing. Just getting into it is better than not doing it at all. This was part of a message during a Unit Testing 'Tech Talk' I helped deliver to my team back home in conjunction with some of my peers.

"Why write unit tests when you write perfect code?!" <- A great quote by Brent Edwards.

The reality is, it's not possible and we don't write perfect code. The way to help at least validate the code and strive for quality is through unit tests. As Jason states, we all want to be Einsteins but in reality we are more like Homer below (image courtesy of Visual Studio LIVE! and Jason Bock):

If you work for a company that 'gets it' you probably already doing unit tests. If not you might be fighting a battle of 'why should I do unit tests when our code and applications have been so successful for years??' Odds are even that 'great' code has flaws and could be a house of cards waiting to fall apart. Unit Tests give us the ability to truly validate existing and new code independently for accuracy.

A question was asked: "How late in the application lifecycle to you want to fail?" The proper answer is not in at the client or even QA but as soon as possible. Like Jason states: "fail fast." Unit Tests help to this end and provide instant feedback when changes or new pieces in our application are not jiving right.

All developers should do some level of testing prior to committing code; this is obvious. What was not obvious was that Jason said he knew folks that would commit untested C# code that doesn't even compile!? Yeah I agree, these are not the folks we want to be working with on our team. Now while simply building the code should be a minimum, we really need a repeatable set of tests to be run as well. By the way, QA is not that 'testing framework' we are seeking. Unit Tests are the solution we need. "Build Succeeded != Ship The Product"

Quick note on design that Jason brought up that ties into the last session. He spoke to folks that use green text for success messages and red text for issues/errors/exceptions. What about color blind people? Maybe rare, but actually a great point. Use check marks and x's somewhat like the unit test runner in VS.NET for a more wide reaching visual queue of the success and failure conditions. I'm guilt of the green/red thing by the way and probably in the last month on a web app. Point taken.

Several of the popular unit testing and mocking frameworks were discussed including the (2) I've used which are MSTest and Moq. Since VS.NET 2012 the integration of outside unit testing frameworks beyond MSTest is much easier to integrate opening a lot of doors to what you are familiar with already. It was an interesting point that RhinoMocks was falling by the wayside, but someone picked up the ball on that project and should help bring it back to life. 

Another almost humorous point was that Microsoft's created 'Fakes' does not work in Windows 8 and Windows 8.1. OK so a Microsoft created mocking framework does not work with their own OS. This results in having to hand roll a lot which is not easy.

The next topic was on the metrics about 'how many unit tests' are enough? There is no magic number. You could have 1000 poor and not meaningful tests or 10 extremely effective tests. The point is to test code by creating tests that are covering the pertinent points of the application.

It was reiterated while showing code examples that mocking is important to allow unit tests to run quickly. Mocking is a way at runtime to replace an interface with an object of known value and behavior used in testing. You will set the value and behavior in the setup of the unit test and use it in the assertions.

Great question was asked: "Which code should be tested?" Jason's response was, "if you write code it should be tested." However he stated he was not a zealot on this either; there are some realities to code and testing, so strive for to test everything when possible.

To wrap up the unit test session, the slide below is colorful and humorous but it actually depicts the harmony and happiness (yes I used those 2 words) that result from the process of writing and using unit tests (image courtesy of Visual Studio LIVE! and Jason Bock):

Wrap Up Day 2

On a small side-note here - I felt bad today because I would be typing here while the presenters were speaking, and being in the front row often they could see me working. They may have thought I was checking email, working, or some other non-related task which would have been rude, but rather I was listening attentively to the session and blogging! If any of the presenters read this I heard all of it and nice job to all of you.

Today was my introduction to the 'Modern Apps Live!' track here at the conference, and I can honestly say I am not disappointed. The only thing I wish is I could have been 2 places at once for the 2nd session today and have attended Brent Edwards' session on  the Modern App Architecture. When I 1st glanced at the track I thought it was going to be just about designing Windows Apps, but that was my misunderstanding of what a 'modern app' was. I'm glad I gave it a look because I certainly learned a lot and got engaged in some good conversations. It's time for a little R&R before Day 3 fires up in the morning!

Award for Best Swag Item :)

Visual Studio LIVE! Orlando 2013 Day 1

It's day 1 and we're going to get into some JavaScript, Single Page Applications, WebAPI and web development (and it turned out a little SQL too) which is all right up my alley. I really enjoy the day long workshops on the bookends of the conference because where as the sessions during the middle of the week are like 'appetizers', the workshops are like a '5-course meal' of the same food genre. This looks to be a popular session as it's quite full, but as usual I scored a seat up front :)

One disclaimer about these posts, it's a test of asynchronous brain power to create these entries. I've described it as being part court recorder, part author, and part student at the same time. I'm not simply regurgitating the material as I hear it. Rather it's a process of listening, processing, learning, filtering, and typing all at the same time. End result, if I mispell (<- irony by the way) a word or have anything stated incorrectly I absolutely welcome feedback, so please just leave a comment.

Data-Centric Single Page Applications with Knockout, JQuery, Breeze, and Web API
Brian Noyes, CTO, Solliance

Right off the bat, I'm hearing great things about SPAa that I normally wouldn't expect; layers and *Separation of Concerns*. Typically when i think of SPAs I'm thinking about slamming a bunch of fancy JS into the UI to communicate with the server via AJAX and databinding. The analogy that Brian used was one that hits home close to explanations I have used: a messy footlocker. What does a footlocker look like that has everything jammed into it and unorganized? These are great analogies for helping to explain why SoC is important, and I happy to see this type of architectural conversation occurring in reference to SPAs. The basic EF architecture and how these queries work is shown below (image courtesy of Visual Studio LIVE! and Brian Noyes):

The next topic nowadays was the plethora of JavaScript libraries available. One of the issues is determining which library to use. Many of the libraries do 1 thing and 1 thing well, but could be retired or morphed into something different too quickly and disrupt the future of your application.

The gold standard at least for now is probably jQuery. It's not a given but it sits atop the stable list of libraries. Some of the other mentioned were Knockout (data binding), Breeze (CRUD data service calls), Twitter Bootstrap (CSS Styles and widgets), and Durandal (full JS framework that ties together with jQuery, Knockout, and Require.js). Several others were mentioned such as Angular, Ember, Backbone, and Foundation. The cool thing is if you learn one of these, odds are you can easily switch to another. Typically the differences are small syntactical differences to do accomplish the same objective. Brian was discussing the comfort level with each library and why he choose the libraries he did to work with on development. A lot of it is just personal preference as a lot of these can do the same thing. One direct comparison was made between Durandal and Angular. Both are data binding frameworks using the MV* composition. The important thing to note is either composes well with Breeze and jQuery.

POJOs is a new term I heard today: Plain Old JavaScript object. Wow, I think to the arguments I've seen online about JS being a true OO language. Of course most of us understand POCOs, so here come the POJOs! If one thing is not stated this week explicitly, I'll go ahead and say it: JS is going nowhere and may eventually rule the world as king of development languages. With it's inherit ability to run across almost any platform it's ranking in current day development is rising to the top if it's not already there. Remember when we thought JS was just some fancy client-side trinket to make alerts and validation? Not anymore, JS is beginning to reign supreme and emerging as a 1st class citizen for all types of development. If you want to be relevant as a software engineer, I recommend having a working level knowledge of JS at a minimum.

TypeScript was brought up and is essentially a higher level language that it's up outputting JS. It helps prevent some of the bad practices of natively writing JS. The allure for me is writing in something more familiar in the style of a strongly typed language, yet creating the JS needed and ran at runtime. I actually hope TypeScript catches on as a standard in is used widespread because I think it will make the process of writing JS much easier. Since it's backed by Microsoft, there is a good chance of this happening. I think it just needs a tad more time to mature and sell itself. This is a good week to make that happen to a wide audience.

Quick list of development tools for client-side development: NuGet, Chrome / IE development tools, Fiddle, Postman, Knockout Context debugger, jsFiddle, Web Essentials, Resharper, and Productivity Power Tools. On a personal note I use or have used about 75% of those, so always good to know I'm not working in a vacuum / cave and unaware of whats valuable. The conversation about the IDE productivity tools like Just Code / CodeRush / and Resharper all help every day developers do stuff faster. Yep there is no need to state it any more elegantly. These tools help what might ordinarily take 4-5 clicks, keyboard presses, mouse-clicks, etc be compressed into 1-2 instead. I personally use and like Resharper but all of the tools do a different flavor of the same thing. As far as the browser tools, I personally use the IE development tools because I am targeting IE so often, but the Chrome tool seems to be particularly useful with it's 'Sources', 'Console', and 'Elements' tabs for debugging code client-side. The ability to debug the JS in the browser using F5/F8 in Chrome was something I have not done, but something I will *definitely* be using in the future.

jQuery which I'm sure most have already used is a rock in the JS world for doing rich DOM manipulation. It helps with normalizing the API for working across browsers. Remember the days of writing large 'if' blocks in JS to account for different browsers to accomplish a single task? With jQuery this issue is almost non-existent as the functionality to determine this is encapsulated and reduces what the developer needs to write. However it is much more that just this as the shorthand nature of all functionality exposed in jQuery greatly reduces the amount of overall JS required to be written. The 'selectors' allow easy reference to DOM elements and then manipulation via jQuery. An example is $("#MyElement").val("Hello"); is a simple way to set the value of a HTML input text box. Once you have your element selected there is a *massive* amount of manipulation that can be done to that element.

One of my favorite parts of jQuery and was presented was the ability to make AJAX calls to the server to return and bind data. I've written about some of the challenges of doing this in reference to ASP.NET web forms (Divorcing the UpdatePanel for Asynchronous Postbacks in Web Forms Isn't Easy), but for SPAs and MVC applications this works really well. The syntax to call a server method (i.e. Controller method) and return JSON to use client side is straight forward. One of the new things I have not seen are JS 'promises' like .done, .fail, and.always, vs. .success, .error, and .complete. The former are suggested as the modern way of doing this analogous to the new async/await functionality in C#.

I will say one of the aspects of JS development that I need to improve on is the organization of the logic. I still can be blamed for placing JS at the top of my pages. If I were writing in a server-side language I would say this type of disorganization violates many code standards, so I need to begin to refactor out this code into meaningful files that are better organized. In my defense this is the nature or tendency though for writing in languages that are not strongly typed and have a tendency to be written in a notepad style as plain text.

Knockout is a data binding JS library that is a means for separation of concerns. It works on all browser and is not dependent on any other libraries. It's size is about 13KB, or should I just say non-existent which is fantastic. It main features are Observables (like INotifyPropertyChanged in WPF/Silverlight world) and UI templating. I have not used observables in JS before, but this peaks my interest. The ability to have changes notify when their properties change in JS closes the gap on client-side vs server-side abilities.

OK WOW! The conciseness of two-way databinding with Knockout is amazing vs jQuery. You can place the declaration directly on the element like: data-bind=" value: name". The Observable nature prevents the need to do traditional 'push/pull' that I had been doing previously with jQuery AJAX calls. At this point even early in the day, if I just improved my JS organization and began to use Knockout, I believe I would be leaps and bounds ahead of where I am today. The thing that begins to get overwhelming is the onslaught of features one wants to apply after learning everything in this week, but the reality is to pick and choose to be productive and move forward. I think it's time 'Knockout' gets into that bag of items to use back at home.

Data binding attribute:

<input data-bind="value: name" type="text" />

JavaScript object to bind to:

var customer = {
Name: "Allen"
};

applyBindings function to bring the two together:

ko.applyBindings(customer);

I also didn't expect to hear about MVVM in this session. My thought was: "here are the 100 newest JS libraries and how they can make your life easier without hardly using C#" OK, that's probably a little generic, but I'm really pleased to see architectural and OO discussions in this track. I definitely scored with this session today as the architect blood running through my veins is at ease with what's being presented. MVVM is a presentation layer architecture to help with Separation of Concerns. For example here would be a typical breakdown:

Model: JavaScript
View: HTML / CSS
ViewModel: JavaScript

Inline styles are a violation of MVVM so layering is needed to provide organization and Soc. The ViewModel will expose properties and logic for databinding and can be analogous to the 'code behind' files from web forms if you need to connect the dots. The Model is typically everything else not in the View and ViewModel. It might be POJO, busniess logic, and validation mixed together. The View is just that; the structure the user sees on the screen.

A complete demonstration was given on Knockout Observables. It was cool to see a simple example of a text box and label where when the text value was changed and tabbed off, the label value observed the update and automatically updated. This wasn't just JS assigning 1 field to another. The Observable was at work and notified automatically when the field was changed.

Knockout Context was a nice add-in to Chrome to help with debugging. Unfortunately navigating through the object model using the native tools does not yield the values of the bound observables. Using Knockout Context allows you to see the actual values to assist with debugging.

The 'Revealing Module Pattern' was an interesting way of structuring code similar to a class in .NET that contained private values and methods to be exposed as a package. The return object is the exposed value of the API to the rest of the code using it. One important thing to note are the parenthesis at the end of the function after the last bracket to make sure that the function is invoked. This structure is used to create ViewModels that then are data bound to for the controls on the page.

A typical data binding syntax looks like data-bind="value: customer().Name" The parenthesis are required to make the databinding work, but there are extensions to Knockout that will allow the removal of parenthesis for a more concise syntax declaration.

Templating in Knockout and in JS in general is something I still have not gotten completely familiar with to date. You can use the following syntax: data-bind="foreach: products" on a
with columns and have them repeated when rendered for the collection. I suppose analogous to some of the Razor Helpers in MVC, but since we are looking strictly at SPAs and JS, this is the mainstream method for data binding a collection of data.

Probably the main distinction to make here is using purely JS vs. a more robust and rich framework like ASP.NET. I see all of these various data binding examples and think "I don't even need ASP.NET" and that is partially the point. However as I mentioned prior in respect to web forms, using purely JS data binding exposes a rabbit hole of issues and challenges. It might not be an "all or nothing" scenario (as nothing in development usually is), but finding the harmony between use of technologies and languages is the challenge I'm still working through.

There was a question on the following line of JS at the beginning of the file:

var my = my || {};

What this does is state if there is already a 'my' namespace or some other library using this namespace, add our code to it and don't void what already exists. However if it does not exist, our binding objects will still be added to the namespace. One of the aspects I really like about the Knockout syntax is the concise yet explicit feel of the code. When I read it having not used it before, it just looks to make sense and be quite readable. Compare and contrast this to raw JS, and it's much easier to read and write.

I did like Brian's explanation of a methodical approach to deciding when to use custom data-binding handlers. The 1st thought is if you want to manipulate an element, you probably are thinking about using jQuery to get that element and then do what is needed. The next question to ask is if you will be doing that same manipulation more than once. If the answer is 'yes', then it's best to look into this type of refactoring and use of binding functionality.

Templating has the following syntax:

data-bind="template: {name: currentTemplate}"

<div id="homeTemplate">
Hello
</div>

In this example above, 'currentTemplate' is our template object that exposed the data for binding and uses 'homeTemplate' by ID.

SQL Server Workshop for Developers
Leonard Lobel, Microsoft MVP and CTO, Sleek Technologies, Inc

OK I I took a U-turn here and hopped over to the SQL Server for Developers workshop. Brian was doing a terrific job in the other workshop, but in lieu of learning a couple of more JS libraries, I got selfish for craving more and varying knowledge so I sunk over here. I peeked at the agenda and there looked to be several topics in the afternoon that seemed to be useful for me to investigate.

I'm catching the tail-end of the SQL 2012 enhancements discussion. A random note that caught my ear immediately is about querying the system information. When needing to get system information query the system view schema as opposed to the system tables which change names in just about every version of SQL released.

XML is the only topic being cover that pre-dates SQL 2008. Leonard makes a great point about never going to extremes when making decisions on a topic. Some camps say we don't even need a relational database because of the structure and validation of XML. The other extreme is to never use XML for storing data and always use a database. There are shades of gray in the middle.You can store the structured XML in the database, but yet still have the advantages of XML querying.

XML in it's raw form can be stored in the database. I know 1st hand from doing this it can be a bit tricky to query as he validated but feasible. One interesting thing which I need to go back and look at some of the databases I worked on is the use of the XML data type for a column. I believe in the past I always used a varchar(max), but if I had a column that is always XML (not say JSON and XML captured from service traffic for auditing) then using the XML type appears perfect. In fact upon querying using 'FOR XML RAW' or 'FOR XML AUTO', the XML appears as a link, and clicking on it produces a well formatted version of the value. This is very nice. In fact you can even relate the XML to a schema (.xsd) and get validation upon inserting into the database. No doubt about it, if I need to store XML in the database again, I'll be using this type. I may not explore all of the functionality available, but even just for storing the data, this appears to be a superior method.

There were also examples of querying using XQuery where in the WHERE clause there were conditions using a XPath expression like the following: Book.value('/book[1]/title[1]', 'varchar(max)') AS Title. This ability extends into doing other CRUD operations as well. The overall concept is that you can query and modify XML stored in SQL server just as you could in a programmatic way from .NET. You are getting the best of both worlds with storing XML, yet being able to query and manipulate the XML in it's proper way.

Next up is something I really do want to get into more and know I'll use it in the future. FILESTREAM in SQL Server. There are (2) options for storing data: inside as a BLOB or outside the database in the file system. BLOBs use a varbinary(max) data type. The bad part of inside the database is the bloating of the database and the eventual pull on performance, and the bad part of being outside the database is the requirement to backup all the files manually.

A few quick side notes on FILESTREAM; it is not supported in mirrored environments. However in SQL 2012, it is functional with HADR (high availability). If you are using this new version of HADR the FILESTREAM functionality works. Also if you turn on TDE, it does not encrypt the files. One last tidbit for the frugal among us, the FILESTREAM files do not contribute to the 10GB database size when using SQL Server express.

The FILESTREAM attribute allows storing the files outside of SQL server with just the pointer to the file. However SQL Server manages these files and brings back the transnational nature of the NTFS file system. With FILESTREAM you get the best of both worlds; reduced bloating on the database and store files where they naturally belong. Once FILESTREAM is enabled, the column needs to be declared with "varbinary(max) FILESTREAM." Notice the data type is the same as before except with the FILESTREAM attribute.

The generation of the FILESTREAM will create a .LDF and .MDF to manage the files along with pointing to a folder that pre-exists to store the files (i.e. 'Images'). I did ask if the files are available to seek out manually on the file system. The response was technically they do, but they are obfuscated and we should not be looking at the files. We actually did this and the file was obfuscated 3 levels deep and each folder and file appeared to be named as a GUID. The file itself had no extension thus not identifying the type of file. You would have to open the file in the appropriate program to see it. However, once you store more than 1 file, there will be little chance you could distinguish between the file names to open what you are looking to find. This example was only feasible because we were working with a single file in an empty directory. Point is, you only access the file via SQL Server.

In .NET one can access these files via System.Data.SqlTypes.SqlFileStream as a stream in the proper way. This method will not place a burden on SQL Server performance (as opposed to querying the database natively which will place a burden on SQL). By using a transaction to get the path after inserting essentially a dummy file, we can stream the actual file to the destination thus bypassing SQL. This way we do not have to allocate any memory on SQL Server's side to store and access the file. Yes even for accessing the file a transaction was used, thus keeping the load off of SQL Server. Using a transaction seems odd to read the data, but the .NET library requires a transnational context, so just accept the process for the byproduct of reducing the pull on SQL Server resources.

An example was provided for the procedure of using a FILESTREAM in a transnational manner from .NET. The idea is to insert everything required except the BLOB column using a 0 length string. Once the values are returned specifically the path name and transaction context, these are used to create and use the filestream thus completing the transaction.

Something new to me is the 'hierarchyid' data type. Its essentially a binary value that has its bits arranged in a certain way to determine the hierarchy (parent, child, sibling, etc.) This type of column can be indexed (depth-first or breadth-first). You can use either or both to meet your needs. It appears this type of data type would be great for hierarchical data stored in trees (org charts, family trees, etc.) I'm sure those of us storing hierarchical data in the past have used a contrived series of numbers creating a path to the location of a node, etc. It has some SQL functions such as GetAncestor() and GetDescendant() to query the hierarchical data. It may not be pretty, but honestly is much cleaner than any hand baked approach.

This data type and functionality could be the solution to storing hierarchical data. It might not be used on every database, but it's another good tool to know about in the proverbial toolbox. I know for a fact I've done the hand baked approach to create treeviews in ASP.NET and the data persistence was not clean. This would have been a better approach if it had existed.

The FileTable was added in SQL 2012. It is a combination of FILESTREAM and the hierarchical data. It appears as an ordinary table with the exception that the schema and columns cannot be dictated. Some of these columns are stream_id (GUID identifier), file_stream (FILESTREAM), name (nvarchar name of directory or file), and path_locator (hierarchyid with location of the file or directory within the file system hierarchy). FileTable exposes a file share with the files stored. Changes are tracked on both sides; if changes are made on either the database or on the file system the other one is updated.

The most interesting thing is that the files are not stored in an obfuscated manner like they are with pure FILESTREAM which means the files are directly accessible. The one caveat are 'memory-mapped' files. An example was shown where a .txt file was attempted to be opened and an error was presented. This has to do with the way Windows uses pointers in virtual memory to quickly open the file. The quick fix to open the file is to just copy it out to another location. I would probably investigate the FileTable feature before FILESTREAM if using SQL 2012 as it seems to align a little more directly with traditional file storage practices.

SQL Server also now has Geospatial functionality, where data pertinent to user's physical location can be aligned and presented. Obviously this would be most useful for mobile development. This functionality has existed since 2008 but has been improved in 2012. The functionality uses either Planar or Geodetic spatial models to locate the position. Geometry (flat model) preforms much better than Geography (curved model), but can be used if the area is small or the precise accuracy is not paramount. There are (2) data types that can be used for the column data: 'geometry' and 'geography'.

One very cool feature is if you query the data, you can click on the 'Spatial results' to see the graphical data. The data used to produce the geographical information can be imported from any of the following sources: Well-Known Text (WKT), Well-Known Binary (WKB), Geographic Markup Language (GML). The data for example in WKT looks like the following: POLYGON ((35 10, 45 45, 15 40, 10 20, 35 10),(20 30, 35 35, 30 20, 20 30)). Obviously we will be importing this information and not creating from scratch. If you do want to try and generate valid results from scratch, I assume you are the same person (yes singular, because nobody should be doing this) that hand writes the vector based coordinates in XMAL :P

One example shown was having (2) photos that were taken and then using the .STDistance() function was their location to determine how far apart they are physically. This is just scraping the surface on what can be done and my mind goes 100mph thinking about the potential. The Geospatial functionality really opens a ton of doors for location based programming and data needs.

One side note on something I have blogged about before (You Can't Know It All (YCKIA), But Keep Pursuing After It Anyway) proving you can't know it all or be perfect at everything. Over the years I have noticed this trend - in purely code sessions, you might see some SQL or stored procs that are a bit rough around the edges. Here in a SQL session, I see top notch SQL and some HTML, JS, AJAX, and C# that is a tad rough around the edges. TOTALLY 100% OK and I know these are just stubbed out examples. However even in examples you can see the main topic being pushed. At the end of the day it's tough if not impossible to be great at everything. That's why I always yield to or at least listen the knowledge of the experienced! This guy has probably forgotten more about SQL that I'll ever know.

The last portion of the day is dedicated to 'Enterprise' features that are only available to SQL Server 'Enterprise' editions unless noted. 1st up is SQL Server Audit. This was added in SQL 2008 and in SQL 2012 they included it in 'Standard' edition as well. With Audit you can track virtually any database action by a user or process and log it to either the file system or Windows event log. How many times have we over the years created an 'Audit' process for SQL Server manually? With this feature we have some inherit functionality available. Now if your auditing does not map flatly to your data structure, this might totally trump your need for custom auditing. For example, just showing that a modification to a record by a user is not enough, and there are combination rules that make up the auditing. However even a rule such as auditing users that delete more than 10 records in a 1 week span; it appears you could take the raw audit records and then create a view incorporating the rules.

The next Enterprise feature discussed is Change Data Capture or CDC. It provides the functionality to record changes to a table’s data into another table without writing triggers. I suppose this could be really useful on tracking changes to a table containing transnational data (i.e. banking deposits) to provide and audit trail what occurred. You can used system functions to query the data. This also has been available since 2008, and imagine was created not only because the functionality is so often sought after, but was being done manually regardless as this type of auditing is sometimes absolutely required.

The final Enterprise feature presented was TDE or 'Total Disc Encryption'. The entire database including the data and logs can be encrypted. This was if backups are compromised they will not be readable with the proper master key and certificates installed on the server. Note that the TDE keys are created at the server level and is why it can be done without modifying individual columns, etc.. The data will be encrypted on the fly as it is stored and read. This fact makes me wonder about the performance hit, but honestly it's probably so minuscule it's not worth blinking an eye. The type of algorithm used as with any encryption will either increase or decrease the performance hit based on it's strength. Often encryption is a requirement so any performance hit is a non-factor and has to be included in estimates.

NOTE: One should not solely rely on TDE for truly sensitive data. If you have columns like SSN, credit card numbers, etc. they should be individually encrypted at the column level. Unlike TDE that is free and requires no work at the query level, column level encryption / decryption does require providing the keys on each access of the data. It might be a small pain, but security when needed can't have a price tag or effort tag attached; it needs to be done.

The TDE process initially does take some time, so make sure you do it off hours if doing this to a production database. He did note that 'tempdb' gets encrypted implicitly if using encryption on temp objects. He recommends storing encrypted databases on a separate instance than non-encrypted databases to reduce the unnecessary nature of encrypting databases that do no require it (like 'tempdb'). I don't believe this is a requirement though and a mix of TDE databases and non-encrypted databases should be fine. What's the old saying: "let's test it and see!"

Wrap Up Day 1

Well that's another great start to this year's VSLive! conference! I'm happy that I switched up to the SQL class after lunch as I was able to pick up a lot of additional information across 2 different topics. Hats off to Brian Noyes and Leonard Lobel for an excellent job presenting; I'm quite pleased with the content. Beginning tomorrow, the traditional portion of the conference begins with the 75 minute sessions. Looking at the schedule there are so many different sessions I want to go to, so I will need to apply some filtering logic of my own to figure out which ones to attend ;)

Award for Best Session Name :)

Up Next... VSLive! 2013 On Deck!

♫"It's the most wonderful time of the year..."♫ Nope, that's not Christmas music you're hearing. but it's time for the premier developer conference here in Orlando, FL to begin tomorrow!

This is my 6th VSLive! conference and I'm hungry for soaking up some technical knowledge this week. As I've mentioned prior, this conference and others I attend like it help make up my DNA as an architect and software engineer. Last year I used a large amount of what I learned on WebAPI back at the office to help bring new products to life.

This year the VSLive! suite of conference introduced the 'Modern Apps Live!' track which I'm interested in getting engaged. I look down the list of presenters and there are a fine group going to be dishing out knowledge with the like of Jason Bock, Rocky Lhotka, Billy Hollis, and Nick Landry to name a few. It's going to be another one of those years where there are 5 things going on simultaneously and only 1 thing I can attend. This is why I value this conference so much.

In the days preparing I've installed VS.NET 2013 and Windows 8.1 on my laptop (yes, I'm still lugging one around, but to it's credit it's super fast with a SSD). I have the essentials (pictured right) to energize and then re-hydrate ;) so there is no question about the stamina required to go 5 rounds (days) with VSLive!

I've already registered and have begun planning for tomorrow. I've got my eyes on the Data-Centric Single Page Applications workshop. The mix of client code technology talk along with WebAPI are valuable needs in my line of work. If you happen to read this and are looking for a suggestion, I highly recommend the 'End-to-End Service Orientation' workshop with Miguel Castro. I've attended, would honestly do it again, and is great if you need to brush up on or learn about services available on the Microsoft stack.

Well, there is not much left to say but let's get it started!

Layers Are Cheap, But Doing It Right Is Priceless

I've often pondered over, discussed, and lightly debated the process of designing small applications and the extent to their architecture and implementation. Usually the conversation surrounds doing it 'quick and dirty' vs. creating a 'well built and thought out' application.

Think of this old saying:

Why do we use that saying? The idea is if you do a job hastily, it will have to be thrown out and started all over again. On a larger scale maybe something like this could occur :P

This is not unlike the process of building software. Odds are if you build an app poorly to try and save time, or create a 'throw away' app not supposed to be used in production both situations will yield a front running Enterprise application. Well, not always but it happens more times tan one probably realizes when making these decisions.  If you create a poorly made application, there is a strong likelihood in the future that it will also be 'thrown out' and targeted for the old 're-write.'

I know in my years of experience I have opened many of applications of all types (web, desktop, services, etc.) that were a huge mess of code. No wonder the passionate in our industry scream from the mountaintops about things like code standards, design, architecture, OOP, unit testing and the like. Who in their right mind with any experience places 1000 lines of code behind a form with a mix of binding, rules, data access, service calls, etc. that cares about the craft of software engineering? All this does is create a pile of frustration for the next developer to jump in someone else's mind to figure out their goo of an application mess. And is there ever any commenting to help with the goo? Of course not, these same developers believe that code should be 'self-documenting.' Yes thank you, please leave me the manual to your brain so I can decipher the poop you wrote, thank you.

So why waste time with re-writing application, if we can do it right the 1st go around? Well typically this scares those concerned with timelines, as doing an application properly is perceived to take longer to create. 

"Ah this is just a little old app, do we really need that fancy design?"

Yes. Or at least closer to 'Yes' than 'No'. In the end the word 'fancy' or 'complex' is overrated and misused anyway. It's cheaper to do than you think. Let's make a real-world example to discuss. Say we are tasked with creating a small web app with a few pages pulling data from the database and in the midst we need to apply a few simple business rules. As usual, it needed to be done yesterday.

1st let's say we choose to use web forms because of it's plethora of server controls which lend themselves to RAD. You could just as easily say WinForms, WPF, or MVC here as well. MVC would naturally have a leg up here because of it's M-V-C architecture that helps start us on the proper path of separating our concerns. However we could still have fat Controllers in MVC and be in the same conversation, so the technology choice here is not the main focal point. We can screw up the implementation using any technology.

Using web forms though we might be tempted with our objective to use one of the more robust data binding controls offered that includes built in data access methods. On the other hand another quick approach would be to use basic server controls and fatten up the single code behind file to get all the requirements complete and done quickly.  All of this are poor decisions that are leading us down the path I described earlier.

I'm not advocating for a full blown Domain Model or Onion Architecture, but a simple 3-layer (UI-BLL-DAL) architecture is leaps and bounds better than a code behind file with 3000 lines of code. If you are an experienced developer or have experience designing apps, how much longer does it truly take to set up the additional logical layers?

Let's see:

1. Right-click, 'Add New Project' (BLL)
2. Right-click, 'Add New Project' (DAL)
3. Add references to new layers, create a few classes for busniess rules and data access.

OK, so this is the super simplified steps but in reality how long does it really take to add a few layers and segregate the application code? Maybe 1/2 day to 1 day for a small application. Possibly a few minutes to hours is more the reality. If you have used this in other applications, there will be some copying and pasting of basic logic (if not already refactored into a common unit) and visually copying of solution structure to help speed things along.

What's the payoff for this small bit of work up front? A MUCH better and well understood application, as well as an application that can scale better and stand the test of time longer. Splash on some code standards and common best-practices and we are making giant strides toward a better application.

I think the reality and success to this is having engineers/leaders/etc. with some experience doing this to articulate how easy this process is. Inexperienced engineers combined with nervous management concerned with timelines will most likely 9 out of 10 times agree together that the 'quick and dirty' route is a great option, and sell themselves on this idea because it's a small, unimportant application. The term 'architecture astronaut' or 'over architechting' are common buzz words that kill a good design and make those in charge feel good about essentially creating sloppy applications.

The summary of my experience is dealing with these poorly written apps is frustrating, and 5x time consuming in the long run as opposed to working on a well laid out application, no matter the size of the application. Since the cost of doing it 'right' or 'better' is so cheap up front, why not just do it? The answer should be that there is no excuse or discussion around not building applications with a well thought out design. The thought process should be applications small to large will all be done well, to prevent the known and true pitfalls that exist when creating applications 'quickly' to save time (which is an oxymoron by nature).

Visual Studio Online Goes Live

Today at the Visual Studio 2013 Launch, 'Visual Studio Online' was announced and is now available for use at: http://www.visualstudio.com/en-us/products/visual-studio-online-overview-vs This was previously known as Team Foundation Service and is a home for your project data and team collaboration in the cloud. Here are the main 'features' taken directly from Microsoft's site:

• Unlimited team projects and private code repositories
• Integrates with popular IDEs, including Visual Studio, Eclipse, and Xcode
• Includes your choice of Visual Studio Express for Web, Windows, or Windows Desktop
• Build your backlog, track bugs and tasks
• Run CI builds on Microsoft cloud infrastructure for easy management of team builds

MSDN Subscribers have access included in their subscription, and small teams of less than 5 can join for free. Larger teams that do not have a MSDN subscription have additional licensing options available. As of right now, it appears it is $10 per month per user as an introductory special ($20 regular price). I'm sure the fees are just to cover the cost of the cloud services for Microsoft, as it behooves them to attract as many users to their suite of services as possible.

As you can see from above, signing in for the 1st time only takes a few minutes as I'm a MSDN subscriber and the process was simple. Looks like this could be a great tool for a number of reasons, so check it out from the link provided.

Divorcing the UpdatePanel for Asynchronous Postbacks in Web Forms Isn't Easy

Point MVC vs. web forms here in the effort to make ajax calls to the server for asynchronous postbacks. This experience made me realize how nice MVC is from this respect I'm about to highlight.

For years I used ASP.NET UpdatePanels in web forms development and overall they have done the job. However, anyone that has used them on mildly complex pages knows, you can't just have 1 UpdatePanel. Nope, you need 2 with the 2nd one having a trigger pointing to the 1st so partial updates will work properly. The end result: a tangled web of UpdatePanel goo.

Recently I decided to use jQuery making AJAX calls to ASP.NET page methods instead as an alternative to UpdatePanels. The jQuery in it of itself may not be 100% cleaner but it works really well and is straight forward. So I create my ASP.NET page method, write some jQuery to make a call to my new page method asynchronously, and walla I have bypassed the UpdatePanel, yeah!

Not so fast...

Caveat #1: Page Method Must Be Static. This will by the way not be ideal for anyone doing Dependency Injection as you will have to Publicly resolve dependencies through methods like: Global.GetInstance()

Caveat #2: Can't see my server side controls from the static method called (because of #1 above and how it's called from the client).

Caveat #3: Normal postbacks later that access or post bound clientside elements complain of security and EnableEventValidation issue.

Caveat #4: Be prepared to query element values via Request.Form and not through control instances.

End result: A worse mess than using an UpdatePanel.

Recommendation: If you are doing ASP.NET web form development here are the (3) choices I recommend:

1. Deal with full postbacks like it's 2002
2. Use an UpdatePanel for asynchronous postbacks and don't mix client side data binding asynchronously with JavaScript.
3. Ditch ASP.NET web forms and do MVC (hey no hater here, I stick up for web forms a lot - just know how the tool operates)

I want to show through an example all of what I just described. So 1st, lets look at a simple example to populate a ASP.NET ListBox server control's items using an AJAX call to the server to just see how this works. We'll make a DropDownList that contains the 'Periods' during a school day. Upon selection we want to have the classes populated in the ListBox. The goal is to do this without having a full postback or use an UpdatePanel.

First a simple set of server controls:

<form id="form1" runat="server">
    <div>
       <asp:DropDownList ID="DropDownList1" runat="server">
          <asp:ListItem Text="Please Select..." Value="0"></asp:ListItem>
          <asp:ListItem Text="1st Period" Value="1"></asp:ListItem>
          <asp:ListItem Text="2nd Period" Value="2"></asp:ListItem>
       </asp:DropDownList>
    </div>
    <div>
       <asp:ListBox ID="ListBox1" runat="server" Width="400px" SelectionMode="Multiple"></asp:ListBox>
    </div>
    <div>
       <asp:Label ID="Label1" runat="server" Text=""></asp:Label>
    </div>
    <div>
       <asp:Button ID="Button1" runat="server" Text="Submit" OnClick="Button1_Click" />
    </div>  
</form>

Next we need a Static server-side event with the [WebMethod] attribute added that our jQuery we will make can make an AJAX call to and will return a collection of 'School Classes' for the 'Period' selected:

public partial class Default : System.Web.UI.Page
{
   protected void Page_Load(object sender, EventArgs e)
   {
   }

   [WebMethod]
   public static List<SchoolClasses> DropDownList1_SelectedIndexChanged(string id)
   {
 if (id == "0")
 {
    return null;
 }

 //Generic code representing call probably to retrieve values from the database
 var classesPeriod1 = new List<SchoolClasses>()
    {
  new SchoolClasses(){ID = 1, Name = "Math 101"},
  new SchoolClasses(){ID = 2, Name = "Science 101"},
  new SchoolClasses(){ID = 3, Name = "Social Studies 101"},
  new SchoolClasses(){ID = 4, Name = "Spanish 101"}
    };
 var classesPeriod2 = new List<SchoolClasses>()
    {
  new SchoolClasses(){ID = 5, Name = "Art 101"},
  new SchoolClasses(){ID = 6, Name = "Music 101"},
  new SchoolClasses(){ID = 7, Name = "English 101"},
  new SchoolClasses(){ID = 8, Name = "Global Studies 101"}
    };

 List<SchoolClasses> results = null;
 if (id == "1")
 {
    results = classesPeriod1.ToList();
 }
 if (id == "2")
 {
    results = classesPeriod2.ToList();
 }

 //this.Label1.Text == "You selected a id = " + id;

    return results;
 }

   protected void Button1_Click(object sender, EventArgs e)
   {
      var selectedItems = this.ListBox1.Items.Cast<ListItem>().Where(li => li.Selected).ToList();
      //The collection is empty?? There were selected items though...
   }
}

public class SchoolClasses
{
   public int ID { get; set; }
   public string Name { get; set; }
}

Lastly, we need the jQuery that is wired up to the 'change' event of the DropDownList that will call our new Static event server-side and populate the ListBox with the results.

<script src="http://code.jquery.com/jquery-1.9.1.min.js"></script>
   <script type="text/javascript">

      $(document).ready(function () {
         DropDownList1_OnChangeHandler();
      });

      function DropDownList1_OnChangeHandler() {
         // Add the page method call as an change handler for DropDownList1.
         // This will call the static page method, and use the returned results to populate ListBox1.
         $('#<%=DropDownList1.ClientID %>').change(function () {
            var val = $(this).val();
            var text = $(this).children("option:selected").text();
            var $timePeriod = $('#<%=ListBox1.ClientID %>');
            $timePeriod.attr('disabled', 'disabled');
            $timePeriod.empty();
            $timePeriod.append('<option value="0">< Loading Please Wait... ></option>');
            $.ajax({
               type: "POST",
               url: "Default.aspx/DropDownList1_SelectedIndexChanged",
               contentType: "application/json; charset=utf-8",
               dataType: "json",
               data: "{'id':'" + val + "'}",
               success: function (schoolClasses) {
                  $timePeriod.removeAttr('disabled');
                  $timePeriod.empty();
                  if (schoolClasses.d == null) {
                     return;
                  }
                  $.each(schoolClasses.d, function (i, schoolClass) {
                     $timePeriod.append('<option value="' + schoolClass.ID + '">' + schoolClass.Name + '</option>');
                  });
               },
               error: function () {
                  $timePeriod.empty();
                  $timePeriod.append('<option value="0">< Error Loading classes ></option>');
                  alert('Failed to retrieve classes.');
               }
            });
         });

      }
   </script>

If you built this example and ran it, the ListBox would populate as we would like. In fact it's really fast too. Originally I thought, "Home Run!" So what's the problem? Well if we have a simple example this might work, but as we need to add to the page, we begin to run into hurdles.

Let's try to add in (2) more features to highlight what I'm talking about:

1. Update a label to state which 'Period' we selected when calling server-side Static method.
2. Iterate through the 'Selected Items' collection on submittal of the form

OK, I know what you might be thinking thus far; EASY! I've done this a million times. Well, let's dig in and look at some of the challenges I listed at the beginning of this post.

First, add this line to our Static server-side method:

this.Label1.Text == "You selected a id = " + id;

Next, add this code to the server-side button click event to iterate through the selected items.

protected void Button1_Click(object sender, EventArgs e)
{
  var selectedItems = this.ListBox1.Items.Cast<listitem>().Where(li => li.Selected).ToList();
  //The collection is empty?? There were selected items though...
}

Now try to run this code. There is already an error with trying to access the Label's .Text property. Why? See #1 and #2 in the original list of issues. In a static method on the page, I can not see or have access to the Page's instance. Makes sense actually. I making a quick call to the server, but not in the context of how ASP.NET would expect, but rather from the client. Still completely legal to have the Static method, just will not behave as we might have hoped.

Comment out the the code to change the Label's .Text property. Now run the page, select some values in the dropdown and press the 'Submit' button. This time we have another issue; a hard error stating: "Invalid postback or callback argument." Why? See #2, #3, and #4. The server did not originally send the data to populate the ListBox, so it is unaware of it. This will cause a security error unless the page's EnableEventValidation="false" property is set. However I don't like to do this because it opens up a security risk and would not be something I recommend in production applications.

However if we do set to false EnableEventValidation, then we still can't see the values from our control, because the Server did not provide them and has no knowledge of them. How do we get them? Well you could use the Request.Form values and manually dig through the posted form to scrape out the elements. At this point, I'm thinking... Yuck.

So in order to make my AJAX call work to interact with the server using asynchronous postbacks and avoiding the UpdatePanel I have to deal with the following:

• Reduce the page's security by setting EnableEventValidation="false"
• Not be able to see any of the control values I manipulated through their server-side properties.
• Have to dig through Request.Form to manually find updated client values
• Not be able to use Dependency Injection as intended
• Have a disorganized mismatch between the client and server state since the right-hand doesn't know what the left is doing.

At this point I think, is an UpdatePanel so bad compared to all of what I just discovered? Let's review the UpdatePanel code again:

<asp:UpdatePanel ID="UpdatePanel1" runat="server" UpdateMode="Conditional">
    <ContentTemplate>
 <asp:ListBox ID="ListBox1" runat="server" Width="300px" SelectionMode="Multiple" AutoPostBack="True" OnSelectedIndexChanged="ListBox1_SelectedIndexChanged" />
    </ContentTemplate>
</asp:UpdatePanel>

Nope, that actually was not so bad. So the end result for a web forms applications was I stuck with the Update Panels and everything worked well in regards to asynchronous postbacks. As I mentioned at the beginning, I think this is where MVC really shines, because there is no state being tracked and updated by the server and causing at least a portion of this mess because of the mismatch between the client updates happening independent of the server knowing about it.

Hopefully you try all of this out and see the caveats of trying to do AJAX asynchronous postbacks to the server via jQuery before going to far down the road on a new project hoping this will work smoothly. There are as I've shown several 'pitfalls' to be aware of so just make sure you factor them in if going down this route.