Child pages
  • Technical Workshop 3 13-3 14 2008
Skip to end of metadata
Go to start of metadata

<html><head><title></title></head><body><div style="float:right">


Purpose: API Refactoring Sprint
Location: Virtual

Date: March 13th/14th 2008


  • Step through core services
    • Admin - Ben
    • <strike>Cohort - Darius</strike> Complete
    • Concept - Dave
    • Encounter - Brian
    • Form - Darius
    • Location - Brian
    • <strike>Obs - Ben</strike> Complete
    • Orders - Ben
    • Patient - Burke
    • PatientSet - (Ignored for now, will be refactored out eventually)
    • Person - Burke
    • <strike>ProgramWorkflow - Mike</strike> Complete
    • <strike>User - Justin/Ben</strike> Complete
  • Other services
    • <strike> HL7 - Ben</strike> Complete
    • <strike>Notification - Ben</strike> Complete
    • Scheduler - (Ignored for now, will be refactored in scheduler branch by Justin)
    • Util - ignored for now
    • Logic - Ignored for now
  • API refactoring in its own branch
  • Hibernate issues
    • Verify whether manipulating domain objects (Hibernate proxies) affects database? It shouldn't.
    • Object passed to create() method adds ID to object – should use saveOrUpdate instead of merge (per Ben)
  • Consistency across services (methods)
    • Hibernate merge vs. save vs. update vs. persist vs. saveOrUpdate
    • Do we return object or IDs?
    • Decide on convention for Set vs. List vs. Collection
    • Getting multiple objects with multiple methods w/ various number of parameters
  • Take most stuff out of admin service (domain object specific methods move to their services)
  • View from Groovy
  • Move all date created and date changed from DAO level to API (service) level
  • Verify if across all services, avoid overwriting (void and create new for each change)? What about person (can't change primary key)
  • Add authorize annotations to API
  • Add consistent calls to API methods:
  • :“Creating location “ + location.getName());
  • :“Updating location “ + location.getName());
  • :“Deleting location “ + location.getName());
  • Do we need includeVoided everywhere? If not, what's the convention/pattern for use across service methods?
  • Does Location get its own service? What's the convention between service-per-region-of-model vs. service-per-domain-object?


  • Ben Wolfe
  • Brian McKown
  • Burke Mamlin
  • Paul Biondich
  • Darius Jazayeri
  • Mike Seaton
  • Dave Thomas
  • Justin Miranda
  • ...?

Primary Goal

A documented, clean, consistent, and easy-to-use API layer.


  1. We will spend 75% of the two days writing/editing/documenting code, and 25% talking
  2. Any philosophical disagreements will be punted immediately — e.g., if agreeing on "voided" versus "retired" would take time, then we’re not going to do it during this sprint


(All times in EDT)

  • 9am-11am
    • We answer all the high-level questions about what a service/impl/dao should look like.
    • Together we go through ObsService, ObsServiceImpl, ObsDAO, and HibernateObsDAO, and fix that up as an example.
  • 11am-2pm
    • At this point we will assign services to teams of 1-2 people.
    • Each team gets a service, and cleans it up
  • 2pm-3pm
    • Reconvene as a big group, code review a few of the teams’ work, and show off any cool thoughts people had
  • 3pm-5pm
    • Re-split into teams, and do another round of services


API Refactoring branch:

Google Doc "whiteboard"


We should have a common template for all services in our API. This allows for easier comprehension and a cleaner codebase overall.

See the API Service Template that came out of this meeting.