3 ms·

I don't get what the problem is here. Each of those annotations modifies the field somehow - if you take one out, then you get less functionality. Is the proble

by cytzol 13y ago

I don't get what the problem is here. Each of those annotations modifies the field somehow - if you take one out, then you get less functionality. Is the problem really "my code does too much"? He says: > I can't even see the damn property under this bloat. To me, all those annotations are the property, so you're seeing exactly what you need to see. You could put it all in an XML file if you really want to, but they're still going to be there, and you'll still have to read around them.

nautic 13y ago
Actually, the property is just a value of a type having a name. The property has the responsibility to hold and provide access to its value. It's definitely not the properties responsibility to know how it is being stored in a database, this is a so called 'mapping'. If you'd change the table name, you should not have to change the property, but the mapping. Another important aspect is readability.
grey-area 13y ago
Just to take the join definition, here it is : @JoinTable( name = "customer_order", joinColumns = { @JoinColumn(name = "customer_id", referencedColumnName = "id") }, inverseJoinColumns = { @JoinColumn(name = "order_id", referencedColumnName = "id") } ) In rails, this would be: belongs_to :customer and maybe has_many or belongs_to on customer for the inverse. and the xml translation is pretty transparent too, under the hood it's not very different, but it's a lot simpler to write/read. It is possible to get rid of a lot of this sort of boilerplate by adopting conventions about naming etc and then specifying the exceptions where necessary. I do think these would be better moved to methods rather than being object attributes like this (which read like a translation of XML into text annotations on the object, rather than convention + code when convention isn't enough).

by cytzol 13y ago

nautic 13y ago

Actually, the property is just a value of a type having a name. The property has the responsibility to hold and provide access to its value. It's definitely not the properties responsibility to know how it is being stored in a database, this is a so called 'mapping'. If you'd change the table name, you should not have to change the property, but the mapping. Another important aspect is readability.

grey-area 13y ago

Just to take the join definition, here it is : @JoinTable( name = "customer_order", joinColumns = { @JoinColumn(name = "customer_id", referencedColumnName = "id") }, inverseJoinColumns = { @JoinColumn(name = "order_id", referencedColumnName = "id") } ) In rails, this would be: belongs_to :customer and maybe has_many or belongs_to on customer for the inverse. and the xml translation is pretty transparent too, under the hood it's not very different, but it's a lot simpler to write/read. It is possible to get rid of a lot of this sort of boilerplate by adopting conventions about naming etc and then specifying the exceptions where necessary. I do think these would be better moved to methods rather than being object attributes like this (which read like a translation of XML into text annotations on the object, rather than convention + code when convention isn't enough).