This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: SOA & Persistence - Its all about Services
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.
I've been contemplating the move to SOA style development for some time now, but recently I've taken the plunge. I'm talking, of course, about giving up OO as a way of life. Not everything is an object.
I have a lot to say on the subject, but my main focus will be on the impact SOA has for developing a system. That's right. One system. Not how to connect different systems using XML Web Services.
On that note, I'd just like to debunk a myth I ran into recently a la 15 Seconds : Realizing a Service-Oriented Architecture with .NET. The following image appears to be "common knowledge" when talking about SOA. Anyone see the problem ?
Hint: its between the Business Objects and the Data/Persistence.
The problem is that persistence is ( or at least should be ) a service. The business objects themselves should not be aware of their persistence. Rather, the services above should use the persistence service in order to perform the work needed.
Instead of: myCustomer.Update();
Should be: Persistence.Update( myCustomer );
Why is this important ? Because it contributes to a separation of concerns ( see Agile Management - Separation of Concerns ). Obviously, putting the knowledge of persistence ( or, for that matter, anything else ) into business objects creates bloated objects that need to know everything about what can be done with them. I'm sure that this will just further inflame the great O/R mapping debate ( see "Futility of Object-Relational Technologies" and "GENerative Object Mapping Layer" ) but it is still true.
Previous Topic
