public class CircuitBreaker
{
public CircuitBreaker()
{
ScheduleTasks = new List<ScheduleTask>();
}
public Guid Id { get; set; }
public string Name { get; set; }
public int? CircuitId { get; set; }
public Breaker BreakerType { get; set; }
public IList<ScheduleTask> ScheduleTasks { get; set; }
}
public class ScheduleTask
{
public Guid Id { get; set; }
public Guid CircuitBreakerId { get; set; }
public string Name { get; set; }
public int StartHour { get; set; }
public int Startminutes { get; set; }
public int DurationInHours { get; set; }
public int DurationInMinutes { get; set; }
}
Följande kodsnutt ovan skapar NHibernate själv upp nya id:n på nycklarna till respektive klass. Jag vill att om jag satt värden är det de som gäller och om jag inte satt några värden så ska NHibernate själv firra biffen. De borde ju gå att lösa, men jag kan inte förstå hur!?
1. Varför vill du sätta ID:n i vissa fall själv och i andra inte?
2. Nej jag tror inte det går, eller ja det går men enbart för för olika objekt.
t.ex. har du ett objekt du alltid vill sätta ID på själv så sätter du generator class="assigned".
3. Du kan använda alternativ 2, och själv sätta ID:t om det inte finns något som du inte vill ha specialsatt med Guid.New();
Men frågan är fortfarande varför vill du sätta ID:t själv?
Oftast så går det att lösa på ett enklare och snyggare sätt.
t.ex. Task som du har där, istället för att säta ID:t
Ja Hibernate ska sätta ID:t åt dig, det är något som har med datalagringen att göra och inget som du ska hantera i exempelvis en DAO. Sen förstår jag inte varför du har CircuitBreakerId och inte en referens till ett CircuitBreaker-objekt i dina klasser, det är väll OO du skall göra och inte en representation av en data struktur :) Ja du kan använda en many-to-one i din Task-mappning för detta
SQL-anropen kan du kontrollera med hjälp av fetching strategies i antingen din mappningsfil eller dina querys. Anropen beror ju på om du använder lazy-load, hur du har implementerat din hibernate sessions hantering och hur du mappat upp dem med fetching.
Ja Hibernate ska sätta ID:t åt dig, det är något som har med datalagringen att göra och inget som du ska hantera i exempelvis en DAO.
Det finns tillfällen då man önskar sätta id:et själv eftersom du inte kan vänta på ditt DAL skall sätta det till dig. Jag har just det "problemet" själv nu när jag stoppar ner data till en kö och behöver använda id:et för att referera ihop det med data som kommer efteråt som också läggs på kön. Nu verkar det ju gå ändå, och det är tur eftersom behovet finns :)
Undantagen som bekräftar regeln :) Visst finns det undantag, men rent generellt om vi snackar om identifierare så är jag av åsikten att det är något som hör till persistens och representerar en relationsdatabasstruktur i grund och botten. Misstolka mig rätt
Jag misstolkar inte, bara utökar informationen lite.
Givetviss så har du rätt i att det inte bör skötas av programmeraren utan O/RMappern/DAL:et/Databasen. Ville bara påpeka att det finns tillfällen där man måste göra det själv, och därför så måste komponenterna klara av att hantera det.
- M
338 ms totalt · 4 externa anrop · v20260731065814-full.a51de22e
