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>();
        }
    }

score 8 · Answer 1 · answered Nov 29 '12 at 19:05

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

+1 for re-stating the difference between POCO and DTO. Seems like a lot of people are too lazy to look at the definitions and happily use one term for the other these days. — guillaume31, Nov 30 '12 at 09:33

eulerfx · Accepted Answer · 2012-11-29T19:00:14.067

Given the above, how would I populate the QuestionBlocks collection?

When reading from a database, the persistence infrastructure should populate the QuestionBlocks collection - reconstitution. Reconstruction should not invoke behavior, it should only set appropriate fields on the POCO. This is the responsibility of the repository. A repository is typically referenced from an application service, which sets up the stage for invoking entity behavior.

If that's the case then what kind of behavior would you put in a POCO?

The behavior in the POCO entity should be concerned with making changes to the entity itself as well as maintaining invariants - ie ensuring the integrity of the entity. In your example, the simplest kind of behavior on the POCO should be method for adding a new question block to the collection on the survey. Ideally, you would make many of the properties on the survey entity read-only:

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

        public void AddQuestionBlock(string questionBlockInfo)
        { 
          this.QuestionBlocks.Add(new SurveyQuestionBlock(...));
        }

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

The persistence layer should be able to set the values of the read-only properties via reflection. You can go a step further and only expose the question blocks collection as a read-only collection to ensure that it can only be modified from within the entity itself.

POCO's, behavior and Peristance Igorance

2 Answers2

Linked