In our ASP.Net project we've got a view with 3 (or even more) cascaded combo-boxes, The question is how should we design our (NHibernate-based) entities given that the relationship between the combo-boxes is relevant only for the sake of building the view, and given that the entire catesian product of the 3 entity types is around 2000 entities.
So the questions are actually:
Should we design the entities as a heirarchy even though the collections has no additional business value (thus making them an overhead for any other scenario)
Should the data be sent as flat rows? keeping the entities more "clean", but requires additional coding on the view's side
Seperate to consequent requests (e.g only after combo A is selected, combo B's data is fetched from the server)? making the entire process maybe more efficient but at the cost of performance and perhaps caching?
Any thoughts?
First of all, you should not design your model (entities) by one intended UI. Today is it 3 dropdown, tommorow it can be autocomplete nad in a week some new fancy "wow" component, but your model should stay solid - it describes actual, business relations between entities, not your current UI. From this, i think it is quite obvious that you should use combination of 2 and 3.