maintaining view lookup data in Domain model?

[emaayan]

hi..

we are struggling with an issue of where or how to bring deocding data of lookup fields, from a domain object model to the view layer, and an idea has been brought up to allow the domain model to hold names of codes (like for example class Benefit will hold benefitCode AS WELL as benefitName), this in order to save database calls (as the names of these codes all reside within a different legacy system).

another suggestion was to create a view model and a service that will fill such a model, and to hold a central table that will hold all codes and names in one place, as well as the type of code to bring.

how was this solved in other places?

[karldmoore]

Is it possible to explain what your after in a little more detail? I think I understand what you are after but it would be great to clarify before I try and answer you question.

[emaayan]

i'm after a generic solution to problem of view data being more 'human' the buisness data.

say that have an object callled benefit, and this object has an attribute called benefitType, which a numeric attributes used to logical descisions, now this object also has premiaCode and which is also used for logical process.
now, the benefit class is presisted in hibernate in our own data schema, but the population of the benefit come from a legacy system which also holds the lookup valus for these codes for example, the description of benefitType 1 is 'basic' and benefiType 2 is 'rider'.
now when displaying the benefit class to the use would also like to include the description, which holds 2 options:
the first open up fields for description in the benefit class of the domain model, and in the same process that populating the class from the legacy system bring about the description fields to the model, thus going through only one trip to the database but when persisting our domain model, creating a data duplication problem, as well as muddling the model with view data, a slight alternative is to populate the domain model once with business data alone, and when populating the model for view, bring the names as well. but still we have to open up fields for this in the domain model.

the other option is to maybe create a replciated lookup table in our schema, and creating a view model which will hold out names of the codes, and when populating the view model, start calling a routine which bring the look up descriptions to view, and take performance hit

we do not use jsp at all, but an infrastucure for data binding using ognl, (the page layout are being defind as xml). so now scriplets or http sessions. just define a text field (or other table object) and attach a property from an object.


i was wondering that solutions other folks have considered.

[sabarish]

the other option is to maybe create a replciated lookup table in our schema, and creating a view model which will hold out names of the codes, and when populating the view model, start calling a routine which bring the look up descriptions to view, and take performance hit

Can't this routine be modified to use a CodesManager class that would be an application level singleton and have it cache all the codes and descriptions ?

[emaayan]

it's posssible althought i'm not sure, i was thinking maybe on create a seperate class for each field of a code, then send the class itself and the code as uniqu identifer for the code, and manage one single table for all the codes.

[debasishg]

Can't this routine be modified to use a CodesManager class that would be an application level singleton and have it cache all the codes and descriptions ?

+1 on this suggestion. Modern day databases also support cache tables (you can declare a table as a cached table), which reduce lookup times a lot. This prevents code clutter at the application level. But since in ur case these data reside in legacy databases, the best option will be to use an application level singleton holding all cached data.

Cheers.
- Debasish

[manifoldronin]

+1 on this suggestion. Modern day databases also support cache tables (you can declare a table as a cached table), which reduce lookup times a lot. This prevents code clutter at the application level. But since in ur case these data reside in legacy databases, the best option will be to use an application level singleton holding all cached data.

I would go for this caching-at-app-level solution, too. But surely we are not suggesting a Java singleton, are we?

[debasishg]

I would go for this caching-at-app-level solution, too. But surely we are not suggesting a Java singleton, are we?

No way !! It's a Spring singleton bean that will cache at app level ..

Cheers.
- Debasish

[manifoldronin]

No way !! It's a Spring singleton bean that will cache at app level ..

I'm putting the gun down.