POCO's, behavior and Peristance Igorance

Question

From what I have read POCO classes should be persistence ignorant and should not contain references to repositories.

Q1. Given the above, how would I populate the QuestionBlocks collection? I have read that POCO's should contain behavior so you don't end of with an anemic model, so I'm kind of confused as how one is supposed to do that without persistence. If that's the case then what kind of behavior would you put in a POCO?

Ex:

 public class Survey
    {
        public int SurveyId { get; set; }
        public string Title { get; set; }
        public int BrandId { get; set; }
        public DateTime Created { get; set; }
        public List<SurveyQuestionBlock> QuestionBlocks { get; set; }

        [ResultColumn]
        public string Name { get; set; }


        /// <summary>
        /// Constructor
        /// </summary>
        public Survey()
        {
            Created = DateTime.Now;
            QuestionBlocks = new List<SurveyQuestionBlock>();
        }
    }

Answer 1

I would append another view: POCO states for objects which are not dependent on any framework. The wiki definition of a POJO is much more meaningful to me then the one for POCO:

• http://en.wikipedia.org/wiki/Plain_Old_Java_Object

To paraphrase the wiki definition of the POJO, we can say that POCO object might not be forced to:

I. Extend prespecified class:

public class MyClass : AnyFramework.ObjectBase {...

II. Implement prespecified interfaces

public class MyClass : AnyFramework.IHaveDependency {...

III. Contain prespecified attribute

[AnyFramework.KeyAttribute]
public class MyClass  {...

Given this (almost anything else is allowed) in the meaning of taking care about the object state. Other words, if object will check Business logic, it is correct.

But any POCO object can be used in a framework. Today it is mostly for ORM which is responsible for persistence. All application tiers are working with POCO objects, while data layer is responsible for loading and persisting (CRUD). This is mostly done via Proxies of these POCO objects.

So, POCO could be used as full business object, which can take care about itself (check correctness of collection items, properties...). This makes it different from DTO