6

According to Initial POCO Design 1-Pager

Persistence Ignorance refers to being able to allow the developer to write and test domain objects in a way that is entirely independent of fundamental requirements and assumptions that may be made by the infrastructure service (in this case, the Entity Framework). Such requirements / assumptions may often include:

  • The need to implement a specific interface (for e.g., IPOCO)
  • Inheritance from a base class
  • Providing specific constructors
  • Object Instantiation/Construction requirements – use a specific factory for instance**
  • The need for metadata or mapping class or property Attributes
  • The need to use specific relationship mechanisms

This amounts to being able to use Plain Old CLR Objects (POCO) so that a developer can author their domain objects free of all assumptions and requirements imposed by the framework. Using this approach, once the domain objects are ready to their satisfaction, the developer can use these classes with the Entity Framework in order for relational database access and persistence.

As of right now (CTP5), is there any way at all to reconstitute a poco using a parametrized constructor? If not, it's hard to see how the Entity Framework can be said to offer persistence ignorance.

Ed I
  • 7,008
  • 3
  • 41
  • 50

1 Answers1

8

You can have as many parameterized constructors as you want, so long as the framework has access to a parameter-less one, which is available by default if you you have no constructors, or if you provide one in addition to the parameterized ones you create.

anon
  • 4,578
  • 3
  • 35
  • 54
  • 4
    So much for having immutable domain objects, no? – Ed I Jan 18 '11 at 00:30
  • I'm not sure what you mean here. Domain Objects "have a life of their own" and have attributes that change. Are you talking about Value Objects? – anon Jan 18 '11 at 00:35
  • 3
    No, I am talking about objects where some of the attributes are not to be changed after construction. See [Mutable vs immutable objects](http://stackoverflow.com/questions/214714/mutable-vs-immutable-objects) – Ed I Jan 18 '11 at 00:46
  • 3
    In that case, you will still be able to mark your setters as private. You're still good to go! (This also applies to value objects.) – anon Jan 18 '11 at 01:00
  • 12
    Also important to note that your parameterless constructor doesn't have to be public. It works with private or protected just as well. – Paul Mar 06 '11 at 21:07
  • Any source about the requirment for a parameterless constructor? – Ella Sharakanski Jun 14 '15 at 09:13