ADO.NET EF 4.0: Working with Plain Old CLR Objects (POCO) Classes
Posted by: Mahesh Sabnis
in Category Entity Framework
Abstract: POCO is the ability to add and use your own custom data classes along with with your data model. In this article, we will explore how to use POCO in Entity Framework 4.0
A common question that comes up while discussing Application Development in WCF, ASP.NET or MVC applications is the use of ADO.NET Entity Framework (EF). .NET professionals having experiences with other O-R-M tools like NHibernate etc. are eager to know about ADO.NET EF and its new features. Although ADO.NET EF was available from .NET 3.5 SP1, the 4.0 release has been very promising for application developers. To learn more on ADO.NET Entity Framework, its history and features, Suprotim has written an ADO.NET EF 4.0 Article Series. Check it out!
Typically application developers who design classes with public properties to use as Data Transfer Object (DTO) usually asks questions about the integration of ADO.NET EF in an existing application framework. Enter Plain Old CLR Objects a.k.a. POCO! POCO is the ability to add and use your own custom data classes along with with your data model. In addition to POCO, we have been provided with the facility of using Model-First approach for developing ADO.NET EF. Here we create classes and relations between them and then reflect this class schema to the database which is used for application development.
Typically if ADO.NET EF is designed using Database Table schemas, then you get all entity classes inherited from EntityObject class along with methods for performing DML operations on the database. This design approach can be useful if the Database design of your application is complete and is not likely to change. However if there are new columns to be added later, the EDM needs to be redesigned (using VS2010 EDM designer.) This sometimes increases maintenance cost.
As mentioned earlier, in ADO.NET EF on .NET 4.0, we have been provided with POCO support, which are traditional classes designed using C#/VB.NET with public properties (DTO in short). A POCO class is not inherited from EntityObject class. In this basic implementation, I am going to explain a simple way of working with POCO.
In this project, I am using the following two tables from a Company database created in Sql Server 2008:
Department : DeptNo (PK), Dname, Location.
Employee: EmpNo (PK), EmpName, Salary, DeptNo (FK).
Step 1: Open VS2010 and create a new Windows Application (or WPF or ASP.NET). Name it as ‘WinForm_Using_POCO’. In this project, right click and add a new ItemTemplate for ADO.NET Entity Data Model, name it as ‘CompanyEntities’. Complete the Wizard and from the Company Database, drag-drop Department and Employees tables. The EDM designer will display the following output:
Now here we are going to create own POCO classes having properties with the same name as the table column. We also do not want any code to be generated automatically. To do this right-click on the designer, select properties and change the ‘Code Generation Strategy’ property from ‘Default’ to ’None’ as below:
This will put only comments in ‘CompanyEntities.Designer.cs’ file.
Step 2: In the project, add a new class file and name it as ‘POCOClasses.cs’ and write the following classes in it:
The above code shows that the Department and Employee classes are having the same properties as that of Table columns. Since one Department can have multiple Employees, in the Department class, Employees navigation property of the type ICollection<> is declared. Since Employee class refers the Department, it contains a property of the type Department. The class ‘CompanyEntities’ is inherited from ObjectContext. This class provides facility to query and work with entity data objects. This class also contains public read-only properties for Departments and Employees of the type ObjectSet<T> which represents Typed entity set used for performing create, update, read and delete operations. The class constructor implements the base class constructor which reads the connection string from the App.Config file, generated using the EDM Designer wizard in Step 1.
Step 3: Design a Form as shown below:
Step 4: Write the following code in the Form1.cs (code behind):
The above code helps to perform CRUD operations on the Database using ADO.NET EF POCO approach. Run the application and test the results.
- An existing application having DTO classes can easily migrate to ADO.NET EF.
- Maintenance cost associated with code will be less
- Easily updatable even if the properties in POCO are changing.
- Loosely coupled from the Database.
- The change in Table column (not-null) will not harm the application model.
The entire source code of this article can be downloaded over here