After extensive consideration (perhaps not of that high a caliber, but who needs quality when you have quantity...), we decided that IBOs are not the right answer for us, and that true value objects will work just fine. I still haven't run any load testing, so it remains to be seen.
I find it annoying that small sets of data should still be modeled, for posterity, as VOs. The other thing is that sometimes the business is just messy. For instance, an individual can have a number of different licenses. They can only have a single of one sort of license, but multiples of other licenses. We treat the former license differently display-wise too, asking for it specifically by type, not merely outputting it in a standardized grid or anything as we handle the latter licenses. Additionally, there may be a historical record of actions taken when the individual was serving in the capacity of that license, however they may no longer hold the license, and we do not care about the license details any longer, but we do care about the actions taken, and the actions taken are each their own value object because they in no way share attributes, but they only have about 5 properties...
I assume there is some better way to do this, and that trying to impose value objects on micro data sets is self-defeating. It seems kind of ridiculous that OOP needs to be so rigid, and it probably isn't, but my encounters with it so far imply that. I am leery of readily-accepting mob-mentality borne of not fully understanding something but never wanting to question the authority of the guru spouting nonsense... That is probably too harsh, but I'm just saying, I'll cut you.
No comments:
Post a Comment