So I’ve been spending some time thinking about how to migrate OpenMRS towards a more micro-service like architecture, as was discussed with some enthusiasm in Maputo. One of the steps in making such a move more feasible, suggested to me by @angshuonline, is to make the OpenMRS data model an isolateable component, i.e., to be able to create a JAR of the various OpenMRS data objects that’s separate from the services, etc.
There are various reasons why this is challenging, but one of the more uniform ones is that every class that implements the Attributable interface has to implement two methods, one called findPossibleValues() and the other called getPossibleValues(), which return, respectively, all the values of type X that match a certain string and all the values of type X. These seem to be implemented in the most straight-forward way possible: get a reference to the relevant service, and use that to query the DB. The problem is that the obvious way to do this is this (taken from Concept.java):
@Override
public List<Concept> getPossibleValues() {
try {
return Context.getConceptService().getConceptsByName("");
}
catch (Exception e) {
// pass
}
return Collections.emptyList();
}
The problem is that this adds a hard dependency on Context, which itself has a dependency on the pretty much the entire service layer in core.
When I search through the code in the OpenMRS Github organisation, there are many implementations of getPossibleValues(), but no code that seems to use this method and the only code I can find that uses findPossibleValues() is a unit test for the Concept class.
Given all that and the fact that the functionality implemented by these methods is easily replaceable, I wondering whether it might be a good idea to just deprecate and / or remove these methods. Any thoughts or comments?
