What connection do you need between the unique identities in the persistent store and the unique identities on the client? Is it possible in your app to separate them?
If it is, then read on. In principle there's no reason for not having different IDs. I understand Barry's points below, and by and large agree (although the pragmatist in me normally wins and I'll deal with the possible futures when I encounter them), but if the abstraction between client and server is so well defined then who cares what your persistence tier does with unique IDs? As long as it looks after itself and maintains referential integrity then let it have whatever it needs. You can pass around its identifiers like any other field. In the client if you have managed classes you get a uid allocated for you for free. You don't have to use this for persistence, but you may choose to persist it. This approach is admittedly less elegant, but it means that you can have a disconnected client creating and destroying things as it wants and interacting with them in any way it wants for as long as it wants without constantly having to poll the persistence layer for ids, or any of the other unfortunate consequences of having the (e.g.) database do the allocation. When time comes to persist it, the persistence tier should be smart enough to figure out what it needs to do with primary and foreign keys and allocate them as necessary to maintain referential integrity. Any half decent ORM will take care of that for you. So, my ugly 2p suggestion is use the uids for your client work and integer ids for persistence. Have both fields on your VOs on both sides. You get uid allocation on the client and referential integrity and reportability in the database. Make sure that the integer ids are null or zero by default on the client and the uids make it through the round-trip to the database. If you are creating objects from scratch server-side with no user intervention then you'll need a uid generator on your server. SP --- In [email protected], "barry.beattie" <[EMAIL PROTECTED]> wrote: > > > > I'm no expert in Flex and RIA development but i have implemented > > creating the ID on the client using the createUUID to generate a GUID > > which by all practible means it will be globally unique. > > unique record identifiers are the domain of the data storage. IMHO, > they should NEVER be generated on the client unless they are place > holders to be thrown away at the first available opportunity and > replaced by the internal data storage ones. and that's only out of > desperation - if you have to generate Id's at all that is. > > the only time ID's need to be created are on new records. to be > honest, it should STILL be the back-end systems job to generate it. > sounds like you've got far too much business logic in the presentation > layer and it's only a short step away from your system being a > two-tiered application. > > Heck, why not go all the way and get Flex to generate the SQL for you > to run on the database? (just overstating it to make a point). > > it comes down to abstraction, separation of concerns. > > what happens if you've been using UUID's of one format and change the > format (ie to numeric Identities) or change databases? are you going > to re-write the client's UUID generation code and re-compile just > because you've changed from SQLServer to MySQL? My argument is that > you shouldn't have to. Flex should keep it's nose out of where it > doesn't belong. > > > Some pureist will think it's crazy to generate the key on the client, > > and I partly agree. But if it works, it works. > > works for today yes. but what will those needing to expand the app in > two years time think of this? > > > In my case i'm trying to build rapid applications and i generally have > > oen app and one database so generating IDs on the client is ok in my > > circumstance... maybe not the best for all. > > ... apart from the fact that the data storage is part of the > application, not tacked-on (and should be factored into the design)... > > the large majority of times you'll be able to get away with it but I > can guarantee that some time in the future some of those apps will > cause you to loose your gains. > > two-tier applications (like VB client-server apps) or apps with thin > middle tiers work because the clients are tightly bound to the server. > But Flex (and Apollo) are still fundamentally disconnected clients. > > application design is looking at the whole app holistically, not as a > vehicle to cram as much as possible into the view. Flex can help build > smart UI's that translate workflows to business processes, but IMHO > Flex is not the whole application. >
