Jag tror jag förstår vad POCO innebär när det gäller objekt men jag är inte helt säker. Innan så jag likställt POCO med ett objekt som är en behållare av data.

De frågor jag har:
1. Om kundobjektet har en orderkollektion i sig är objektet POCO?
2. Om kundobjektet har en metod som heter AddOrder är objektet POCO?

poco är rena clr object.
dvs sådana där du skapat klassen själv. så svar ja

http://en.wikipedia.org/wiki/POCO


"POCO is an acronym for Plain Old CLR Object. It is a play on the term POJO, from the Java programming world, and is used by developers targeting the Common Language Runtime of the .NET Framework. Similar to the Java context, the term is used to contrast an object with one that is designed to be used with a complicated, special object frameworks such as an ORM component. In .NET terms, the word is most often used in the programmatic sense, to differentiate a non Serviced Component (see MTS) from a "standard object". It can also be used in a tongue in cheek manner, referencing the perceived complexity of Java based programming frameworks such as EJB."

-> Andreas
Är det ja på båda frågorna? Men när blir objektet inte POCO? Jag har lite svårt att förstå vad man menar med CLR. Jag kan tänka mig att om objektet har en databaskoppling då är objektet inte POCO, eller?

-> Jon
Jag har läst den texten men jag tycker inte den ger en förklaring på ett enkelt sätt vad det är. Jag tycker texten är ganska flummig.

hej.

PCOO betyder i enkel förklaring för att inte vara för jobbiga. Att de kan leva utan massa andra usings.

Ex ta ORMs som exempel där du måste i vissa ORM-ramverk ärva IEntity, eller Entity eller nått liknande för att fungera är inte POCO klasser.

Det är helt enkelt rena klasser som bara har sånt som ingår i systemobject o språket typ.
I ditt fall om AddOrder så why not?

POCO brukar oftast rellatera till just ORM där arv kan krävas där ex attribut måste finnas. Man vill helt enkelt ha objekt som inte skall kräva ett vist ramverk. Säg att du kör med Attribut i dina objhekt för mappa dem mot db då måste du ha en refference till ett ORM ramverk. Vad händer om du vill använda ett annat ramverk? Då är dina entiteter bundna till ett annat...

Sök på POCO i google så hittar du massa svar... Men tänk dig en klass som bara ärver System.Object (vilket de gör by default) och sen har kontakt eller arv med dina egna domänobjekt som i sin tur bara ärver system.object... Så är du så mkt POCO du kan vara.

Undantag är självklart service klasser, factories m.m. som har mer uppgifter för sig...

Mvh Johan