I am working on a project and I am using Entity Framework 4 as my ORM. I am implementing POCO classes. Every example I see with EF 4 and POCOs implements all properties with public setters. Is that the only way I can use POCO classes with EF 4? Do all my setters need to be public?
A:
Use the POCO generator http://visualstudiogallery.msdn.microsoft.com/en-us/23df0450-5677-4926-96cc-173d02752313
http://blogs.msdn.com/adonet/pages/walkthrough-poco-template-for-the-entity-framework.aspx
they are virtual for change tracking (if that is what you want)
Raj Kaimal
2010-05-05 21:56:22
I understand why the properties are marked virtual but, why do the setters of the property have to be public? I have ids on object that I do not want outside objects to modify.
William
2010-05-05 22:04:00
How will the property be set then?
Raj Kaimal
2010-05-05 22:17:01
That is the question, I am asking. I have properties that are object identifiers, that should not be modified once the object is loaded/created. It seems this is not possible if I am using EF 4 and POCO classes.
William
2010-05-06 03:10:33
You can change the T4 template to make all properties private but I doubt it will work because when the object is loaded/created, it has to set those properties.
Raj Kaimal
2010-05-06 03:16:54
Is this how you want the classes to be generated using the POCO generator? http://rogeralsing.com/2009/05/21/entity-framework-4-immutable-value-objects/
Raj Kaimal
2010-05-06 03:24:15
@Raj: e.g. NHibernate can handle private/protected setters. (It can be done using reflection.)
Steves
2010-05-06 14:30:00
I have sent a question to the group. Will let you know.
Raj Kaimal
2010-05-06 14:53:38
+1
A:
It depends how you use your entities.
"POCO" entities are kind of a lie (in any framework). True POCOs, which might have private or non-virtual state and no provision for serialization, can't do change-tracking. The only thing you can do with them in O/R mapping is materialize them.
So whey people talk about mapping "POCOs", there is usually some form of compromise to allow for change tracking. They're not really "POCOs"; they're "so-called POCOs."
One way to compromise is to make all persisted state public. Then you can do change tracking via snapshots.
Another way to compromise is to make all persisted state protected/virtual. Then you can do change tracking via proxies. It is not necessary for the properties to be public.
The EF doesn't support parameterized constructors (yet), so constructor injection (probably the best solution for your case with a "pure" POCO) isn't an option right now.
Craig Stuntz
2010-05-06 13:33:55