Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Stateless Biz Objects Question
Message
De
05/01/2000 19:28:30
 
 
À
05/01/2000 16:59:19
Information générale
Forum:
Visual FoxPro
Catégorie:
Classes - VCX
Divers
Thread ID:
00313483
Message ID:
00313613
Vues:
53
>>Sounds like were on the same path. Your ideas are interesting. Some sort of XML implimentation will probably be the way to go - got alot of reading to do.
>
>How about a table on the server side that stores a record for each persisted piece of "state", with an ID identifying it for future use, and a MEMO field containing XML? Should perform pretty fast, especially with Rick Strahl's fast wwXML class to parse the XML in and out to a cursor.
>


Hold on here, lets figure out what kind of state we're trying to preserve. If all you are trying to do is prevent an update conflict, this can be handled with a timestamp.

When changes are saved to a table, the record gets a timestamp (a datetime field). When a client gets a copy of the record, he also gets the timestamp. When he tries to update the server record, the server compares the current timestamp to the one in the dataset that it is trying to save, and if they are different, this indicates a conflict. What you do in case of conflict is up to you. At the time of conflict, you have both sets of data at hand (one is still in the table), and you have not had to 'persist' anything.

There should be no need to preserve data state like you are contemplating. There are lots of things that do require that state be saved, but this state is usually tied to a session. This can be handled with a custom state object, and persisted to a memo in a session table with wwXML's ObjectToXML method, and retrieved using its counterpart XMLToObject method. Using these, you are not limited to the number of variables (Properties) you can save, but I think the sort of state you are trying to preserve indicated that you are on the wrong track.

Properties like fOEF and AllowDeletes have no business in a stateless business object, except for use internally. What sort of UI are you going to have that will allow or disallow deletes from session to session, and require that the business object keep track of it? This sounds like more of a use for a user table/object that holds rights for specific users.
Erik Moore
Clientelligence
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform