On Wed, Jan 7, 2015 at 6:35 PM, Rohit Yadav <rohit.ya...@shapeblue.com> wrote: > Hey Daan, > > Good points. I've always despised TOs (maybe also because I lack the > understanding of their existence and use), it's confusing to have TOs > when you've VOs to have same set of structural encapsulation they > provide (for example instance/domainrouter/router/cpvm/ssvm related VOs > and TOs). I think of them as unnecessary baggage, like some > anti-pattern. In my ideal world, TOs should not exist; VOs and DAOs are > enough.
Well, i only partly agree. Transfer Objects and Value Objects are conceptual different things. Their implementation requirements are quite similar, though and could warrant a single implementing class(-hierarchy). We have quite a lot of interfaces that warrant transfer objects. Some of those might model the same real world object while requiring diffent data fields. but A consolidation consideration is never bad. I am wondering if someone has the rationale available by head or wiki. more thoughts wanted, > > > On Wednesday 07 January 2015 10:05 PM, Daan Hoogland wrote: >> >> H, >> >> I had a go at a bug in 4.4 over christmas that was caused by NicTO >> inheriting from NetworkTO. I noticed Kaushik solved this bug in master >> and I think 4.5 so I copied some of his fix to 4.4.3 (thanks Kaushik) >> I think the issue is however in the modelling of the objects. A Nic is >> not a special case of a Network. It is hooked to a network, contained >> in a network or has a network. I am willing to have that semantic >> discussion. >> >> In the branch bugfix/TO-hierarchy-flatening I am experimenting a bit >> to see what makes sense in the context of the realworld and cloud >> stack. >> >> I noticed that the TO hierarchy does not match the VO or DAO hierarchies. >> >> Is there anybody who is having any thoughts on the subject?
