This post originated from an RSS feed registered with .NET Buzz by Udi Dahan. Original Post: Objectspaces, SOA, and what comes between them Feed Title: Udi Dahan - The Software Simplist Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple. This blog is about how I do it. Latest .NET Buzz Posts Latest .NET Buzz Posts by Udi Dahan Latest Posts From Udi Dahan - The Software Simplist

Following Ralph Westphal's ( highly recommended ) post on objectspaces - ObjectSpaces questioned: Should object persistence really be thought of as orthogonal functionality? sprung up an email conversation that deserves to appear online, so here it is:

Udi:

The difference in an OOA is not so much how the data is passed, but what you can do with the data once you have it. Say that client code passes a customer object to an OrderManager object. The customer object has a Delete method, so, the OrderManager object has the ability to delete the given customer. Even more alarming, in an OOA, the OrderManager object will be running in the same thread with the same permissions as the client code.

You see, in an OOA, everybody can get into everybody else's innards. In SOA, all the OrderManagement service would receive is a customer entity - a copy of the data. Sure, the service could try to go and delete the customer with the persistence service, but then it would have to do it with it's own permissions.

Ralph:

in my view, persistent objects should not (!) have a Save() method. it might look very attractive ...