Saw a post from G. Andrew Duthie regarding some more new features coming in ASP.NET which is all good, but one of the most significant of those for me (even though relatively minor) is the SQL Cache invalidation. I like to design with caching where possible, but having immediate update of data as well as the benefits of cached data together has not been easy and this feature alone could be immediately usable in a number of enterprise apps I have designed/developed. Great stuff. (p.s. You can find G. Andrew Duthie sys-con radio interview here)
Also saw a post from Martin Spedding regarding user experience and building software that users would love. It reminds me of numerous conversations with my wife, who is not very computer literate, about the useability of software. As far as she is concerned, every application should only have one big button on one big form that has the label “Just do it” and that button should “just do what she wants”. Hmmm ... might be a while before I can develop an application that intuitive. Still working on my “System.Telepathy” namespace....;-)
Actually received some comments on my previous blog entry re: remoting and Indigo most of which says that remoting is not going away, MS wouldn't do that, I should re-read the posts and so on, most of which I agree with (apart from re-reading the posts) but I still think remoting (in its current form anyway) will fade to some degree and be a part of the underlying technology and implementation, rather than this clear distinction between remoting and web services as there is now. But hey, thats the nature of speculation...might be wrong, might be right... would love to be at the PDC getting the info from the horses mouth, but I'll have to be content with virtual attendance through the current attendees blogs...:-)
Just saw a post here by Jesse Ezell that states that MS will be dropping remoting support.
Quote: Yes, it is final, MS is dropping .NET Remoting support.
and this is further underlined by a post here by Drew Marsh covering Don Box's presentation that states
.NET Remoting is awesome, infinitely extensible, but not the future. It will be supported for a long time, but the future, as Microsoft sees it, is more along the lines of what ASMX provides today.
so while remoting isn't going to be immediately dropped, its future is limited, although an approximate time limit is unclear. I like remoting and have used it extensively in many systems I have designed but it looks like this inclination of mine needs to be changed to be inline with future direction. I am sure a viable migration path will be provided my Microsoft as we move forward, I just hope its a nice warm fuzzy one ;-)
The message is clear though. To design for the future, dont use anything too remoting specific, or at least make it flexible enough to support a service-oriented design/architecture when required, to eliminate/minimise rework in the future. I guess a very general way to look at it is, “How easy can I make this remoting call/conversation a web service(s)?“.
Looking forward to more PDC posts.....
Wow, lots of posts from the PDC. Hope everyone is having fun and learning lots <insert jealous sigh here>.
Saw a post to a list of VS.NET Tips and Tricks and I thought I would add some that I have only recently learned and find useful.
1 or 2 are duplicated, hope you dont mind. :-)
VS.NET IDE Shortcuts
(Note: '+' indicates hold down together, ',' indicates subsequent key presses i.e press key, release, then press key)
Shift + Alt + Enter = Toggle Full Screen Mode.
Ctrl-M , Ctrl-M = Collapse current class to definition.
Ctrl-M, Ctrl-O = Collapse all code to definitions.
Ctrl-M, Ctrl-L = 'Un-collapse' all to full code.
Ctrl-R, Ctrl-R = Toggles wordwrap.
Ctrl-I = Incremental search eg. Hit Ctrl-I, then start typing search phrase, text will be highlighted and search for as you type phrase.
Ctrl + Shift + V = Toggle/cycle through code snippets in clipboard ring.
Ctrl + Shift + U = Make all selected text uppercase.
The next version of .net promises some really cool things. Here is a link to an article by Jason Clark on the MSDN site which describes one of the cool new features being added, Generics.
On a recent project, of which you may be vaguely aware of if you read my earlier posts, we had great success utilising XML Strongly typed datasets, to help us maintain the clients state, without actually using any of the state management features within .Net.
Many have discouraged use of strongly typed datasets for a variety of reasons, and they certainly have their drawbacks, but I find them extremely useful. Our scenario is as follows :-
The client has a huge amount of information per page, and there are appoximately 10 different pages in the total process of information gathering for this application. It is web based, and at any point in time, a user can close the application, from wherever point they are, and resume the process of information entering, with all previously entered information intact and easily retrievable. Not too different from many apps out there (if a somewhat vague description of our application).
Our approach for state management, consisted of designing a workflow component as an XML Schema (XSD), within Visual Studio.NET and generating a class file from that. This workflow component contained, an application ID, the state of information entry for each stage of the process (ie. had the user entered info for page 1, has page 1 info been validated, has the user entered info for page 2 etc...), client ID, and various other bits and pieces. We used a 'base page' from which all pages inherited from which exposed a property for getting and setting this strongly typed dataset. When the property was set, the strongly typed dataset was serialised to a string and stored in the viewstate of the page, when the property was read, the string was extracted from viewstate, and read into the strongly typed dataset. So all of this information was retained at the client for every single page.
When the workflow was extracted, this provided enough information for us to grab whatever page information was required from the database, as identified by our application ID, the client ID, and populate the relevant page. Sounds simple enough and it worked extremely well. Unknown to us, during testing of this application, the testing team had numerous 'connection dropouts' as they were using a standard ISP over a modem. When the connection was restored, simply refreshing the page allowed the app to resume as if nothing had happened. (Note: Authentication was achieved using Forms Authentication and cookies so the cookie was still valid and thus the user still authenticated to use the site).
Because of the ease and generic method of serialising the workflow to viewstate, we could add properties to the workflow easily within VS.NET designer, and have these available and automatically held at the client without any coding, apart from actually adding the property within the XML/XSD designer.
As a downside, this obviously added weight to the page, however the page weight was heavy due to the amount of information being gathered so this extra weight proved insignificant in the overall scheme of things. The workflow component was in itself not that complex, so some of the complexities/nuances of coding with strongly typed datasets were also not evident.
On the scalabilty front, this also means that a client can hit any web server in a web farm, and further down the path, any app server, and their information is retrieved with all information integrity retained. No use was made of session ID's at all, and in fact, session state were disabled for this application.
This particular method is not for everyone, and simply suited our scenario extremely well, but does serve to highlight a benefit of using strongly typed datasets. Note that this could easily be achieved using a class of your own design without any XML strongly typed fandangled stuff, but its a bit more work, and this proved extremely quick, effective and flexible. This technique could also be extended to encrypt the workflow itself, before being stored within the viewstate for added security if desired.
Again, this probably wont suit everyone, but it may provide enough food for thought to help with you with state management for your next web application.
If you need or are interested in more details, feel free to drop me a line at firstname.lastname@example.org