|Table of Contents|
OpenMRS has been designed to have a tiered architecture. The real strength of OpenMRS is in its robust and flexible data model. However, not all users want to have to know this data model inside and out. The API layer allows a developer to only have to know Java objects and read/save to them. This layer can be used in a standalone application or, as most people use it, in a J2EE web application.
Hibernate is an excellent Object Relational Mapper. Using just xml files, we are able to describe the relationship between all of our tables and our domain (POJO) objects (like Patient.java, Concept.java, etc). Looking at the concept domain in the datamodel, we see that it consists of tables named concept, concept_answer, concept_set, concept_name. It would be very difficult to keep up with where to store each part of the concept object and the relations between them. Using Hibernate, we only need to concern ourselves with the Concept object, not the tables behind the object. The concept.hbm.xml mapping file does the hard work of knowing that the Concept object contains a collection of ConceptSet objects, a collection of ConceptName objects, etc. To add a new name to a concept:
ConceptService conceptService = Context.getConceptService(); Concept concept = conceptService.getConcept(1234); ConceptName newConceptName = new ConceptName("some name", "some locale"); concept.addName(newConceptName); conceptService.updateConcept(concept);
OpenMRS uses ? Maven to manage the libraries and build system. See that wiki page for more info.
See OpenMRS has a modular architecture, meaning that "modules" (i.e., add-ons or extensions) can be added to the system to add new behavior or alter existing behavior. OpenMRS Modules hosts publicly downloadable modules; these can be installed directly from within OpenMRS as well. See the Module documentation for developers. Modules are allowed to interact with OpenMRS on every level. They can provide new entries into the Spring Application Context, new database tables, new web pages, and even modify current service layer methods.
That spring descriptor file also contains settings for the max form upload size, locale changing, message names, fieldGen handlers, and name/address templates (to be removed: TRUNK-368 ).
DWR is largely being replaced with REST Web Services as of 1.9+.