From the response to my previous post of a few days ago on the subject of server-side validation, it seems some of you remain unconvinced as to its need and continue to hold the belief that the client is responsible for all data validation.
Primarily, the argument seems to be that it's not needed if you're writing both the client and server components - that you're happy to rely on your own ability as a front-end developer and not bother with server-side validation. In this post, I will attempt to demonstrate how even data with a high level of accuracy can benefit from server-side validation, and how you can do that validation in an entirely inobtrusive way.
Monday, 3 August 2009
Server-side validation: a follow up
Labels:
.Net,
Design Patterns,
Good Practice,
Validation
Sunday, 2 August 2009
Flex persistence patterns
It is rare you will find a Flex application that doesn't require data persistence of some sort, whether it be to server via remote objects or web services; or saving locally to an SQLite database as in the case of AIR.
Working on various projects throughout my Flex life, I've come across many different approaches to how this is done, especially in the context of Cairngorm. Exhibit A:
[as3]
// Create my user
var myUser : User = new User( "John", "Smith" );
// Dispatch a Cairngorm event to save it
new UserEvent( UserEvent.SAVE, myUser ).dispatch();
[/as3]
This is the simplest method but, should your event design change, or you want to pass in another argument, you have potentially a lot of code to change where that event may be dispatched. Also there is the added complication that this code could be just about anywhere.
Working on various projects throughout my Flex life, I've come across many different approaches to how this is done, especially in the context of Cairngorm. Exhibit A:
[as3]
// Create my user
var myUser : User = new User( "John", "Smith" );
// Dispatch a Cairngorm event to save it
new UserEvent( UserEvent.SAVE, myUser ).dispatch();
[/as3]
This is the simplest method but, should your event design change, or you want to pass in another argument, you have potentially a lot of code to change where that event may be dispatched. Also there is the added complication that this code could be just about anywhere.
Subscribe to:
Comments (Atom)