Announcement Announcement Module
Collapse
No announcement yet.
Initializing sets of "static" domain objects Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Initializing sets of "static" domain objects

    This question is a little similar to some of the "getting services from the domain layer" but I think it has a slightly different slant. How would you load a set of "reference" domain objects?

    To illustrate the point, let me use not my own requirements but instead an analogous example: that of the States of the USA. There's only 50, they change rarely, and there's data associated with them. To make the analogy complete, let's say there's a domain class Address with a zipCode attribute. One of our requirements is that we have Addresses with zipCodes set, and we need to compute the State (in the actual app the "State" changes with time, so we need to do the calculation at runtime). So the method Address.getState() calls the StateManager.locateState(zipCode), and it performs a complex calculation to locate the proper one of the preloaded States.

    We struggled with several things for this one:
    1) Where to store the State data?
    2) How/when/who to load the State data?
    3) How can Address locate the StateManager?

    We are trying to follow a layered architecture with "vertical" domain layer as diagrammed in the "Expert Spring MVC" book. No dependencies allowed from the domain to services.

    We rejected these designs:
    A) Have an AddressService compute and set the State based on zipCode when Addresses are loaded/saved. Can you guarantee that all Addresses will be caught? What if someone creates an Address and then calls getState()?

    B) Have the StateManager go to the DB on startup and load the States. No domain->service allowed.

    In the end, we implemented something like this: the State data is in an XML file. The StateManager is a Singleton (eew), created by Spring (there are other services that need the data it manages) with a factory-method, and then an init-method call to load and parse the XML file. The Address.getState() makes a StateManager.getInstance().getStateFor(zipCode) call.

    I hate this design. Not only does it have the Dreaded Singleton, but it seems to break the design symmetry somehow. It seems inelegant and out of step with the rest of the app, which is more classic Spring/Hibernate.

    Is there a better way to handle this? Alternate designs?
Working...
X