Jag tror jag förstår vad POCO innebär när det kommer till domänentiteter men jag är inte helt säker. Man brukar väl skilja på feta och tunna domänentiteter och POCO är väl ett annat ord för en viss typ av tunn domänentitetstyp, eller?
Vad innebär POCO?
3 svar · 570 visningar · startad av Lukaspojken
Jag skulle inte säga att POCOs har någonting gemensamt med just domänentiteter, vare sig tunna eller tjocka. :)
POCO kommer ursprungligen från Java's motsvarighet POJO (Plain Old Java Object), och betyder ju då Plain Old C# Object eller kanske oftare Plain Old CLR Object. Det är ett objekt som är väldigt "loose coupled" (vad heter det på svenska?) - och inte beror på andra objekt. Den bör inte ha några tajta relationer till andra klasser, och använda så få referenser till andra objekt som möjligt.
Ex:
public class MyPOCO {
private int x = 5;
public String Name {
set; get;
}
public int DoubleX() {
return (x*x);
}
}
Klassen har inget explicit arv, inga referenser till något extern objekt och är så enkelt det bara kan bli egentligen. Visst skulle man kunna kalla klassen för tunn i och för sig, det är väl inte helt fel. :)
Jag tror vi är inne på samma spår. Men anta att det finns en kollektion i objektet, tex kund-objektet har en kollektion av beställningar. Om jag förstår det hela rätt så skulle ett sådant objekt vara mindre POCO än det objekt du gav exempel på, eller?
Jag känner dock att jag har svårt att skilja på vad som är ett tunt objekt och ett POCO objekt. Kan du eller någon annan förklara skillnaden? För om jag förstår dig rätt så är det inte riktigt samma sak.
Då skulle jag nog inte kalla det för ett POCO, om det finns en kollektion av beställningar (och du använder generics såklart, är det en enkel kollektion utan typbindning så är det fortfarande ett POCO).
Det enklaste är om du läser in dig på coupling, både loose och thight. Loose coupling innebär att objektet beror så lite som möjligt på andra objekt och klasser, utan arv eller instanser till andra objekt. Ju mer beroenden som finns inbakat i objektet, desto tajtare blir det. Ett vanligt, hemskt, exempel på thigh coupling - som beror på dålig inkapsling - är:
class DoTaxes {
float rate;
float DoColorado() {
SalesTaxRates str = new SalesTaxRates();
rate = str.salesRate;
...
}
}
class SalesTaxRates {
public float salesRate;
public float adjustedSalesRate;
public float getSalesRate(String region) {
salesRate = new DoTaxes().DoColorado();
...
}
}
Båda klasserna beror i det här exemplet på varandra, och p.g.a. thight coupling och dålig inkapsling kommer allt garanterat gå åt h*lvete.
Så jag vet inte om man kan säga att det finns olika nivåer på hur mycket POCO en klass är, utan antingen är det ett POCO eller så är det inte det. :)