Re: N-tier development and modeling

        Hi Tom and all,

Tom Hallman <[email protected]> wrote:
> Greetings to all,
> 
>    It is my hope to draw from the experience and expertise of those among you
> who are more familiar with Modeling than I.
> 
>    Here is the situation: my colleagues and I are attempting to put together a
> framework using an N-tier methodology, with the client software interfacing to
> the server/database backend via remote procedure calls (RPC). For us, Modeling
> will serve as a large part of that backend, with an API written overtop. The
> client will make calls to this API, and all will be grand.

Nice!

>    The problem we are having is that of maintaining state between the server
> and the client. For example, if we fetch a set of Person objects to be
> displayed on the client, and then want to perform a delete on one particular
> Person object, how do we know which Person to delete? Modeling seems to work
> wonderfully up to where there is no RPC necessary, but once we add a split
> over the RPC interface, Modeling seems to lack a natural way to refer to
> objects across that divide.
> 
>    One thought we had is to set the primary (and foreign?) keys as class
> properties, such that we can refer to them across RPCs. This is somewhat of a
> hybrid of Modeling and the old-fashioned "use the primary key to get what we
> want" method.
> 
>    Any thoughts on this matter would be greatly appreciated! Thanks so much
> for your time.

Working with PKs and FKs would work, but it is definitely not the
cleaniest way to identify objects wrt the framwork.  There is a
dedicated component for that purpose: the objects' GlobalID (it can be
accessed through obj.globalID() or by asking the EC for the
globalIDForObject()); a GlobalID is a unique identifier for an object/a
row inside a framework.

  Two different kinds of GlobalIDs exist:

- KeyGlobalIDs identify objects that exists in the database, and
  uniquely identify such an object in whatever EditingContext.

- TemporaryGlobalID uniquely identifies a new object that is not saved
  in the database yet.  Because the objects is not saved, such an
  globalID can identify the object only in its referring EC, or in one
  of its children.

Both can be easily marshalled/unmarshalled, e.g. transformed to strings
and back to GlobalIDs; for example, a KeyGlobalID can be rebuilt from
its entityName() (string) and its keyValues() (dictionary).

  Last, given that you have a gid, you get the corresponding object in a
  EC simply by calling: obj=ec.faultForGlobalID(gid, ec)

Does this fulfill your needs?

I still have a question: will you also have an EC on the remote-side?
I'm asking this, because if this is the case the synchronization of the
client's EC and the server's one could be more complicated then simply
identifying objects by their globalIDs and passing some of their changed
attributes. And since I'm currently working on synchronization between
ECs and optimistic locking (working well, I think a first draft wil be
available this week-end), maybe I could also begin to think of such a
"remote" synchronization, esp. if you have a use-case and can consider
testing it in your own app.

-- Sébastien.



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click