Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>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:</p> <p>-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.</p> <p>ex (in psuedo-code):</p> <pre><code>Person = { PERSON_ID:'1234567jksjgkhsduw0909wueioksgt', FIRST_NAME:'CHRIS', LAST_NAME:'MCCALL', TITLE:'', GENDER:'M', LAST_NAME_SUFFIX:null, Addresses = [{ADDRESS_ID:1234,...}] } </code></pre> <p>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</p> <p>ex:</p> <pre><code>Person = { name:'Chris McCall', primary_address:'123 Main St', secondary_address:null } </code></pre> <p>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.</p> <p>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.</p> <p>Different architectures have differentnames for the View Model (which is what I call it). DTO is another name.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload