title: WCF SOA: CRUD Data Access Service...why bother (or is our design wrong)?
body: <p>We have a Data Access service in our SOA WCF system. This service is responsible for doing CRUD (create, update, delete) operations on "system wide" database tables, and is also the source of this data for queries. Any other service in the system wanting to access the tables under the contol of the DAS have to go to the DAS to get it or modify it. We use Entity Framework and built our own POCO state tracking system for this DAS.</p>
  
  <p>We have other tables in our database that belong to single services and store data only for their own use, ie state information they can access if they crash and resume or recording of business information. We have a rule any one table cannot be accessed by more than one service: so data needed by multiple services ends up in the DAS.</p>
  
  <p>Truth is I have never really understood why a Data Access Service is a good idea as opposed to just accessing tables directly. It seems to be to be slower, our DAS is not transactional as it cannot send back a POCO graph for database update (only single POCOS at a time) and we have issues also where the DAS is actually a client to another service which needs data from it...circular dependancy.</p>
  
  <p>Why bother with a DAS? Why is a DAS so important when it comes to SOA? What am I missing here? Single point of control?</p>
  
  <p>Is it also an SOA design flaw that not all tables are part of a DAS and that some services have their own "private" tables?</p>
  
  <p>Any discussion about this welcome.</p>