I remember reading that one abstracts the low level calls into a data agnostic framework (eg. ExecuteCommand methods etc), and the other usually contains business specific methods (eg. UpdateCustomer).
Is this correct? Which is which?
I remember reading that one abstracts the low level calls into a data agnostic framework (eg. ExecuteCommand methods etc), and the other usually contains business specific methods (eg. UpdateCustomer).
Is this correct? Which is which?
To me this is a personal design decision on how you want to handle your project design. At times data access and data service are one and the same. For .NET and LINQ that is the case.
To me the data service layer is what actually does the call to the database. The data access layer receives the objects and creates them or modify them for the data service layer to make the call to the database.
In my designs the Business Logic Layer manipulates the objects based on the business rules, then passes them to the data access layer which will format them to go into the database or the objects from the database, and the data service layer handles the actual database call.
I think in general the two terms are interchangeable, but could have more specific meanings depending on the context of your development environment.
A Data Access Layer sits on the border between data and the application. The "data" is simply the diverse set of data sources used by the application. This can mean that substantial coding must be done in each application to pull data together from multiple sources. The code which creates the data views required will be redundant across some applications.
As the number of data sources grows and becomes more complex, it becomes necessary to isolate various tasks of data access to address details of data access, transformation, and integration. With well-designed data services, Business Services will be able to interact with data at a higher level of abstraction. The data logic that handles data access, integration, semantic resolution, transformation, and restructuring to address the data views and structures needed by applications is best encapsulated in the Data Services Layer.
It is possible to break the Data Services Layer down even further into its constituent parts (i.e. data access, transformation, and integration). In such a case you might have a "Data Access Layer" that concerns itself with only retrieving data, and a "Data Service Layer" that retrieves its data through the Data Access Layer and combines and transforms the retrieved data into the various objects required by the Business Service Layer.