Fwd: DDD-principer
Anders Asplund
> Javadocen.
Bra kommentar, tar på mig att fixa det.
> Skulle AbstractEntity kanske implementera getId() och ta
> ett ID i sin constructor?
Funderade på något liknande men kan tycka att en implementation blir ganska otydlig om vad som är dess id:
public class Person extends AbstractEntity<PersonalNumber> {
public Person(PersonalNumber pn) {
super(pn);
}
}
men det kanske inte är skäl nog...?
...och vill man generera sitt id på så skulle följande implementation kunna exemplifiera det så här:
public class TestEntity extends AbstractEntity<UUID> {
private TestEntity(UUID id) {
super(id);
}
public static TestEntity newInstance() {
return new TestEntity(UUID.randomUUID());
}
}
> Men ni tycker alltså att implementationen av equals är bra, där equals
> returnerar true for id = null på båda objekten?
Detta borde tämligen bara bli ett problem om man låter databasen generera entitetens id genom att likställa PK och ID. I princip tycker jag inte man borde göra detta, dock förstår jag att det är väldigt smidigt.
>
> Ser i så fall hellre att man tar bort final från equals() och hashCode().
Håller inte med. Per definition(och enl. javadoc) så identifieras en entitet av sitt id, detta kan inte garanteras om man släpper på equals.
En av tankarna från början med ramverket var att få hjälp med boilerplate för ddd-driven design på datalagret. Jag kanske är lite fundamentatlistisk men för mig är vikitgt att hålla på dessa principer då jag tror att det i slutändan resulterar i bättre kod.
//Anders
Niklas Gustavsson
>> Skulle AbstractEntity kanske implementera getId() och ta
>> ett ID i sin constructor?
> Funderade på något liknande men kan tycka att en implementation blir ganska otydlig om vad som är dess id:
>
> public class Person extends AbstractEntity<PersonalNumber> {
> public Person(PersonalNumber pn) {
> super(pn);
> }
> }
>
> men det kanske inte är skäl nog...?
Problemet, efter att ha tänkt lite mer på detta är hur man får det att
lira med JPA eftersom den kräver en default cstr och sen lite magiskt
petar in värdena. Det blir då svårt att på ett vettigt sätt sätta id
fältet.
>> Men ni tycker alltså att implementationen av equals är bra, där equals
>> returnerar true for id = null på båda objekten?
> Detta borde tämligen bara bli ett problem om man låter databasen generera entitetens id genom att likställa PK och ID. I princip tycker jag inte man borde göra detta, dock förstår jag att det är väldigt smidigt.
Håller också med om att detta snarast är att betrakta som en bugg i
entiteten. En bugg som jag för övrigt har i *alla* mina entiteter (men
dock avser fixa).
>> Ser i så fall hellre att man tar bort final från equals() och hashCode().
> Håller inte med. Per definition(och enl. javadoc) så identifieras en entitet av sitt id, detta kan inte garanteras om man släpper på equals.
Men vem är det som ska garantera det? Ser inte att ramverket i varje
situation ska vara garanten. Att ramverket erbjuder en vettig default
tycker jag är bra, men jag är inte lika säker på att aldrig ska
tilllåta en subklass göra det själv.
/niklas
Annica Sunnman
/**
* {@inheritDoc}
*/
@Transactional(propagation = Propagation.REQUIRED)
public T store(T entity) {
if (entity.getId() == null || entityManager.find(type,
entity.getId()) == null) {
persist(entity);
return entity;
} else {
return entityManager.merge(entity);
}
}
Vilket om nu DDD principerna skall följas så borde följaktigen inte
denna metoden existera?
Man borde ju kunna få garantera själv att ett objekt skall insertas
med antingen ett id eller en pk genererad från databasen. Hade inte
förstått tidigare att detta inte var fallet men det ger sig väl i
Javadocen om den uppdateras.
Att två null värden returnerar true på equals tycker jag fortfarande
är ett grundproblem. Antingen borde inte null värden tillåtas alls för
att undvika att man hamnar i ett läge där objecten anses lika även om
de inte är det samt att man kan får välja om man nu vill generera id
från databasen.
/Annica
Annica Sunnman
smygit sig in en liten long istället för Long - så mitt ursprungliga
problem löste sig.
Men tycker fortfarande att man skall kunna göra override på equals vid
behov. Genererade nycklar borde tillåtas.
Anders Asplund
Niklas Gustavsson
> Att två null värden returnerar true på equals tycker jag fortfarande
> är ett grundproblem.
För att förtydliga så håller jag med, två entiteter med ID null ska
inte ge true från equals.
/niklas
Anders Asplund
> är ett grundproblem.
//Anders
David Rosell
> > Att två null värden returnerar true på equals tycker jag fortfarande
> > är ett grundproblem.
true ;)
public final boolean equals(final Object other) {
if (other == null) {
return false;
}
if (other == this) {
return true;
}
if (getClass() != other.getClass()) {
return false;
}
@SuppressWarnings("unchecked")
T otherType = (T) other;
if (getId() == null || otherType.getId() == null) {
return false;
}
return new EqualsBuilder().append(otherType.getId(),
getId()).isEquals();
}
(och hashCode delegerar till object.hashCode om entiteten inte hunnit
få sitt id.)
Men frågan är kanske om man skall plocka bort detta beteende...
Anders Asplund
> true ;)
Hade faktiskt inte verifierat detta tidigare
> (och hashCode delegerar till object.hashCode om entiteten inte hunnit
> få sitt id.)
>
> Men frågan är kanske om man skall plocka bort detta beteende...
hantera detta om vi tillåter null-id:n.
Enl. hashCode-kontraktet så skall det bl.a alltid generera samma
nummer oavsett när det körs ( http://download.oracle.com/javase/6/docs/api/java/lang/Object.html#hashCode()
). Så är ju inte fallet nu...
//Anders
Anders Asplund
> hantera detta om vi tillåter null-id:n.
entiteten med ett ID redan när den föds. Det blir nog svårt att från
ramverket tvinga fram ett ID (Niklas hade ett förslag tidigare men som
visade sig svårt att implementera tillsammans med JPA). Om detta är ok
för er så fixar jag det.