Exactly what does really POCO mean, according to dependencies?

With NHibernate child collections are retrieved as NHibernate.Collection.Generic.PersistentGenericBag<>. This is exactly what I here mean by "dependencies" Basically attempt to save/update an item graph, the DAL will curently have it's "opinion" by what &lifier how I am attempting to persist it.

Initially, I figured that asking for a POCO would carry no depencencies towards the DAL, repository, ORM (unsure what's correct term within this perspective). However I am confused, as I am thinking maybe it simply implies that the POCO class doesn't have persistence techniques Which locating a POCO object graph can always carry such dependencies?

Then when you discuss POCO, what you may not mean? Can a POCO have these kind of dependencies, and whether it may And could not, how can you "by title" distinguish individuals?

A POCO that "doesn't have such dependencies" appears a lot more like a DTO, in certain respect, but could have behavior, therefore it is not really a DTO in the end.

Also, simply to be 100% sure: I suppose a DTO could be persistent ignorant And also have "no dependencies" ?

Maybe "dependencies" isn't the proper word to make use of, so just in case correct me. I really hope my real question is still understandable.


With a few further thinking Maybe my assumption the ...PersistentGenericBag introduced by using it some "dependencies" is wrong (?) Most likely it is simply a kind, and absolutely nothing more magical. And additional the only dependencies the objects need to NH, are through the ISessions, which obviously, we've treatments for. Does which make sense?

Getting no dependencies in your objects about your 'DAL' is very an paradise. However, the way in which NHibernate has solved it, comes quite close IMHO.

IMHO, the word POCO implies that your organizations (domain objects) should not need to inherit from the certain base class, or implement some interface for your DAL to operate.
This is actually the situation with NHibernate. However, indeed NHibernate requires additional courses of instruction for collections (such as the Iese.Set class), but chiefly since the .Internet framework did not possess a 'Set' class in those days.
NHibernate uses its very own collection classes, however in the majority of the cases, you -the developer- aren't troubled with this.

When following a Domain Driven Design concepts, your organizations could be POCO's, however, your organizations aren't just DTO's. An entity ought to be a representation of methods that entity appears like within the real life, with data and behavior.

A DTO should indeed be persistant ignorant, as it is an item you can use to transfer data between layers. Among the 2 layers shouldn't necessarly become your DAL. Use a DTO for example to transfer data out of your business layer for your view-layer.

POCO are classes without any dependencies on frameworks or other infrastructure class. Well, NHibernate DOES make use of the PersistentGenericBag however your POCO is only going to reference an IList class.

For the POCO, it does't matter if the instance is a List, a ReadOnlyList or perhaps a PersistentGenericBag, he'll address it being an IList and can produce other behavior that's less than him cope with.

Incidentally, if you are mapping your Domain Objets with annotations you realize possess a clearly dependency towards the ORM.