Question

We have a classic order management application developed in Java on a Controller / Service / DAO architecture. Data objects are POJOs representing the data in the database. Basically we have 1 class which maps 1 table in the database but we don’t use any ORM or entity mechanism These data objects are passed between all layers to create/modify/get orders through Web GUI.
This application also has a WebService layer which allow external systems to manage those orders through SOAP. The WebService layer relies on the Service layer to make sure same logic is used between WebService and GUI.

We try to make the WebServices API as stable as possible but, as we are currently using our data objects as parameters of our WebService methods, that API is likely to change frequently (at least each time we had or modify any field in the database). Moreover, we would like to hide some complexity of the database structure to WebService clients. For example, the database contains multiple fields which we would like to hide from the clients.

Concrete question(s):

• What kind of design pattern is commonly used to hide database
  structure and fields through client API?

• Are there any good practices to handle “mappings” between public
  methods parameters and internal data objets?

• Is the Data Transfer Object the answer to my question?

Answer 1

You should not be passing data objects across process boundaries. It makes your application brittle and guarantees a lot of rework every time you make a schema change. My suggestion is this:

-The data access layer should be just that: dealing with Creating, Reading, Updating and Deleting database objects. Users of the DAL must know how the database works in order to use it.

ex (in psuedo-code):

Person = {
PERSON_ID:'1234567jksjgkhsduw0909wueioksgt',
FIRST_NAME:'CHRIS',
LAST_NAME:'MCCALL',
TITLE:'',
GENDER:'M',
LAST_NAME_SUFFIX:null,
Addresses = [{ADDRESS_ID:1234,...}]
}

etc
-The service layer transforms database schema to hide complexity and cast opinions on what’s really useful to the developer trying to make apps with this data

ex:

Person = {
name:'Chris McCall',
primary_address:'123 Main St',
secondary_address:null
}

You may decide to include the ID or not. You may decide to change the case on the field names, and you might project the data into a form that makes more sense to the app developer, and is more stable than your database schema. Maybe you leave a bunch of stuff out, so there’s less data going over the wire. Stuff like that.

Your DBAs are tasked with making a database that performs well and maximizes storage via normalization. That’s a different goal than the service layer, which does not expect the results of its calls to be persisted.

Different architectures have differentnames for the View Model (which is what I call it). DTO is another name.