Over the last week or two I have been working on our web services story for the work we are doing around the Entity Data Model. Hopefully I can do a screen cast with some of the thinking in the next couple of weeks.
Over this time, however, I have been thinking of a blog that I had been threatening to write for some time... the blog is around how people think about data persistence. There seems to be two categories of data persistence, let's call them instance based CRUD and activity based CRUD. ORM stacks often do really well with instance based CRUD, this is the kind of activity where one updates data in a trivial manner reflecting changes for an entity instance in whole to the persistent store. ORM stacks do not typically do well with activity based CRUD, activity based CRUD typically consists of contextual persistent operations on one or more elements in a graph, such operations are efficiently served through DML or stored procedures, the typical ORM solution for such an activity requires retrieving all instances to be touched in memory, touching them and persisting them (of course Hibernate now supports DML and there are other stacks like iBATIS that handle this scenario well).
In an occassionally connected or distributed world I wonder how useful instance based CRUD is as opposed to activity based CRUD. For example if I have a composite client that has reference data for CRM information and I want to have a UI for managing my leads and activities; when I make changes to instances on the client should I have to send the entire graph of touched instances over the wire? I would much prefer to be able to just express my "intent" to the remote service and interact with well defined contracts specific to my intent. For example if I want to complete an activity I would like a well defined service operation such as:
completeActivity(String activityNotes, ActionItem followOnItems)
which allows me to send over any notes I made and an array of any new ActionItems that are a consequence of the completion of the Activity. On the server side the operation can apply the appropriate business logic in reponse to the completion of the activity and persist the data.
It seems to me that most update operations would be contextual and better suited to activity-style operations as opposed to instance-CRUD-style operations. Create operations on the other hand seem to be good candidates for either instance-style or activity-style persistence.
Now this thinking is not terribly new, in fact folks at Microsoft have been writing about the mismatch between instance-style CRUD and services for some time:
CRUD, only when you can afford itArchitecting industry standards for SO
It seems if we are going to invest in a persistence model that compliments our focus on Service Orientation we need to take this into consideration. Surely some folks will still want to do instance-style CRUD, but if we are intent on truly supporting SO moving forward we need to make sure that the activty-style operation is supported.
[url=http://ypyfkvgm.com/jtom/vpqd.html]My homepage[/url] | [url=http://thskvjdh.com/mxek/tngz.html]Cool site[/url]
I think that you are using an argument for message-based thinking between occasionally connected clients and services, and painting the persistence with the same brush.
Using things like the Unit of Work Pattern, when the service receives your message, it opens a unit of work, and starts doing that "instance-based CRUD" you describe for O/R mapping - updating multiple entities, and finally commits the unit of work.
This is how we solve the apparent conflict between O/R Mapping, the Domain Model Pattern (http://udidahan.weblogs.us/2007/04/21/domain-model-pattern/), persistence, and OCC.
PingBack from http://workfromhomecareer.info/story.php?id=23810