Right now, there are three objects that seem to make up the business tier trifecta:
Now, the core J2EE patterns have a more distinct separation of these objects, into a wide variety of beans. Yikes. Too many things already. So that leads me to the main question:
I can see that an IoC framework might rearrange the session, entity, DAO and object components of the Session facade, but where to I put things like metadata? And then, how can I use that information in something more akin to an MDA method to leverage that information. My case:
Users enter data into a form. The form has several menus on it that are affected by other fields and their selected values. They create cascades. It's like having a MedicalRecord object with attributes of PatientGender and RecordType. If the user has selected Male, for example, the value for PapSmear should be dynamically removed.
So, great Seam gods, I beseech you. You've gotten me to start to consider Java/J2EE again, but there's just nothing I can see here about strategy, not the how, but the why of doing one thing or another. Why make one bean stateful and one not? Should I put things like factories, that may provide the lookups desired, on the Home? Or the Query? On a custom bean? Thoughts?
Annnotations, enum classes, and even custom validators just to enforce model restrictions? Or do I go retrograde, creating lookup tables. Those kinds of things are good for transaction system, but they're really bad for knowledge systems. Too many joins, and with disk space inexpensive, just annotate the field and store the full text value (better for BIRT et al as well). Don't put
2 in the column, put
So, what's the strategy direction here? Or, just how do you think you should do it? From the Seam docs, I note several different approaches.