Entity Framework FAQ: Entity Classes

[[articles:Entity Framework FAQ|Back to EF FAQs Table of Contents]]

     

Is it required to use the code generation tool? Can I hand-author entity classes?

The [[Entity Framework]] does not require code generation. There are facilities for code generation, and some of the UI/designer surface is geared toward those scenarios because they work well in a number of situations, but it is also possible to author your own classes by hand and use the Entity Framework that way.

EF 4 supports POCO. This means that you can use "plain-old" CLR objects (POCO), such as existing domain objects, with your data model. These POCO data classes (also known as persistence-ignorant objects), which are mapped to entities that are defined in a data model, support most of the same query, insert, update, and delete behaviors as entity types that are generated by the Entity Data Model tools. For more information, see Working with POCO Entities.

EF 3.5 SP1 supports IPOCO. That is, you can have classes that do not inherit from an EF base class, but they must implement certain interfaces and they must have specific attributes in order to work with the EF. For more information, see Implementing Custom Data Class Interfaces (Entity Framework).

From http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=573966&SiteID=1

Is it recommended to modify tool-generated classes?

No, because if you do, then you won't be able to regenerate them without losing your changes.

For information about how to avoid overwriting customizations to the object layer, see How to: Customize Generated Data Objects (Entity Framework).

From http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=573966&SiteID=1

Does the Entity Framework require objects with public empty constructors?

While the default generated classes have an automatically supplied public parameterless constructor, there's nothing in the framework that requires that it be public. There must be a parameterless constructor, but it can be internal or private. You can try a simple example by taking the generated classes and adding in a private parameterless constructor. At that point the generated factory method will work to create instances for users, but the system will use the private parameterless constructor to materialize objects that are the results of queries.

From http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=573966&SiteID=1

Does the Entity Framework require objects with public accessors for properties that are to be stored in the database? Does the Entity Framework support read-only properties?

The system does not require public settable properties for all fields that are persisted to the database. While the default generated classes have public properties for each persisted field, you can either write your own classes or set the access for the getter and setter in the designer (public, internal, protected, or private). The Entity Framework does not, however, support properties which only have getters and no setters, and it does not support classes which have only fields and not properties.

Does the Entity Framework support a private field to be mapped to the database?

The system doesn't currently allow you to persist to a field directly. As noted above, however, you can simply make the generated property private.

Does the Entity Framework support inheritance for methods or properties that do not map to the database?

Certainly. You can add these methods or properties to partial classes for your data objects or directly in POCO classes. They will not be persisted, but derived types will inherit them.

From http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=573966&SiteID=1

What are the entity types supported by the Entity Framework?

For information about different entity types and some performance considerations, see Working with Objects.

When should I use self-tracking entities and when are EntityObject derived types or POCO classes a better choice?

Use self-tracking entities when you are developing an N-tier application where you are serializing entities to a disconnected tier and then need to serialize them back with changes tracked. Note that self-tracking entities have lazy loading disabled by default. To load related objects, use eager loading with the Include method.

If you do not need to serialize your objects to a disconnected tier, either write your own POCO classes or use EntityObject derived types. The ADO.NET Entity Data Model tools generate EntityObject derived entity types by default, because these classes provide a number of services automatically: the object context manages the relationships between your objects, tracks changes as they occur, and supports lazy loading in the most efficient manner. POCO classes on the other hand give the developer the most control over his or her entities.

Why does a self-tracking entity's state not get updated to Modified after its property has been modified on the client?

 You should always make sure that your client references the self-tracking entity types (STEs) and not WCF proxy types generated when you added the service reference. For more information, see Walkthrough: Serialize Self-Tracking Entities.

How can I store a set of self-tracking entities in ViewState for an ASP.NET application?

 See the following blog post: http://blogs.msdn.com/b/adonet/archive/2010/05/26/using-binary-serialization-and-viewstate-with-self-tracking-entities.aspx.

Where can I find a graph iterator solution for self-tracking entities?

 See the following blog post: http://blogs.msdn.com/b/adonet/archive/2010/06/02/working-with-sets-of-self-tracking-entities.aspx.

How can I avoid getting objects with duplicate keys in the graph when working with self-tracking entities?

The following blog discusses different approaches to avoid having duplicate keys in the graph:  http://blogs.msdn.com/b/diego/archive/2010/10/06/self-tracking-entities-applychanges-and-duplicate-entities.aspx.

How can I use self-tracking entities in Silverlight?

See the following blog post: http://blogs.msdn.com/b/adonet/archive/2010/05/14/self-tracking-entities-in-silverlight.aspx.

Why doesn't Function Import work when generating code with the Self-Tracking Entity Generator Template?

After creating a new EDMX model and importing a function, the functions are generated in the designer. If the same action is performed by using the ADO.NET Self-Tracking Entity Generator Template the function definition is lost, even though the .tt file contains the "Function Imports" region.

This is unfortunately a bug in the self-tracking entity template. The EF team hopes to have an updated version available with this and a few other updates soon. For the time being, you can copy the code that outputs the function imports from the default ADO.NET EntityObject Generator Template. See a correction proposed by Morten: http://pastebin.com/sLbECkBg.

How do I know what change-tracking strategy is used: change tracking with proxies or snapshot?

There are occasions when you would like to test whether your POCO object is actually a proxy. When you create a POCO entity by using the CreateObject method, if the POCO type does not meet the requirements described in Requirements for Creating POCO Proxies(Entity Framework), a POCO entity will be created instead of a proxy object. For more information, see http://msdn.microsoft.com/en-us/library/ee835846.aspx.

Why are my entities not change-tracking proxies, even though all the properties are virtual?

A common reason not to get change-tracking proxies even if you have made all your entity's properties virtual is that you haven't made your entity's collection navigation properties of type ICollection. For more information, see http://msdn.microsoft.com/en-us/library/dd468057.aspx.

How are complex type properties tracked in POCO proxies?

If a POCO entity contains a complex type property, changes to members of the instance of the complex type will be detected through the snapshot method even if the entity has a change-tracking proxy. However, if a new instance of the complex type is assigned to a property, the change of the property is tracked in the same manner as other properties.

One of the proxy creation rules is that all properties must be marked as virtual. Thus, properties of complex type must be virtual, even though they do not take advantage of notification-based change tracking.

Are there any performance considerations when using POCO?

When working with POCO objects, you can improve the change-tracking performance by creating POCO change-tracking proxies. POCO change-tracking proxy objects notify the Entity Framework about changes as they occur. Alternatively you can use the change reporting model which involves reporting a pending change to a property, setting the property, and then reporting that the change is complete by using the IEntityChangeTracker interface. For more information, see Identity Resolution, State Management, and Change Tracking and Tracking Changes in POCO Entities.

Are pre-generated views available when working with POCO?

Yes. Pre-generated views, compiled LINQ queries, and automatic metadata caching work with POCO in the same way as generated EntityObjects.

What are different options to customize entity objects?

The Entity Framework tools generate partial classes. Having partial classes enables you to extend these classes by using custom methods and properties in a separate source file without having to worry about losing your customization when the generated files are refreshed. For more information, see How to: Customize Generated Data Objects.

You should also consider using T4 templates with the ADO.NET Entity Data Model Designer to customize generated data classes. For more information, see How to: Customize Object-Layer Code Generation.

You can also add business logic to your Entity Framework application by handling the events that are fired during certain operations, such as changes to properties or relationships. For the list of events and examples, see Defining Business Logic.

Another option is to use custom data classes with your data model without making any modifications to the data classes themselves, as long as the names of the entity types, complex types, and properties in the custom data classes match the names of the entity types, complex types, and properties in the conceptual model. This enables you to use POCOs, such as domain objects, with your data model. For more information, see Working with POCO Entities (Entity Framework). You can use the POCO template to generate persistence-ignorant entity types from a conceptual model. The template is not included with Visual Studio but can be downloaded from the Visual Studio Gallery.

Does the Entity Framework support cloning of entity objects or do I have to do it manually?

It depends. If you know that the Reference entity has no relationships loaded, you can clone by using something like standard binary serialization. However if you are unsure, the safest option is to do a manual memberwise clone of the data you need.

[[articles:Entity Framework FAQ|Back to EF FAQs Table of Contents]]