ADO.NET EF 4.0: Working with Plain Old CLR Objects (POCO) Classes

Posted by: Mahesh Sabnis , on 6/23/2011, in Category Entity Framework
Views: 65343
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:

EDM Designer

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:

adonet-ef-code-generation

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:

adonet-ef-poco-classes

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:

clip_image002

 

Step 4: Write the following code in the Form1.cs (code behind):

adonet-ef-poco-sample1

adonet-ef-poco-sample2

The above code helps to perform CRUD operations on the Database using ADO.NET EF POCO approach. Run the application and test the results.

Advantages:

  • 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

Give a +1 to this article if you think it was well written. Thanks!
Recommended Articles
Mahesh is having 10 years of experience in IT education and development. He is a Microsoft Certified Trainer (MCT) since 2005 and has conducted various Corporate Training programs for .NET Technologies (all versions). Follow him on twitter @maheshdotnet


Page copy protected against web site content infringement by Copyscape


User Feedback
Comment posted by Juan on Friday, July 8, 2011 7:55 AM
Muy buen post, especialmente completo, te dejo +1!
Comment posted by phalguni bhuyan on Tuesday, November 15, 2011 8:47 AM
Excellent........
Comment posted by MAhesh Sabnis on Sunday, December 18, 2011 11:24 PM
Hi Phalguni Bhuyan,
Thanks a lot
Regards
Mahesh Sabnis
Comment posted by Pradip on Wednesday, December 21, 2011 3:12 AM
Fabulous work.......keep it up.....
Comment posted by keora mal on Tuesday, January 15, 2013 7:42 AM
tor kheye deye kono kaaj nei bal
Comment posted by Sulakshana D. on Thursday, April 4, 2013 4:29 AM
Good Article
Comment posted by walid on Monday, August 26, 2013 3:22 PM
Nice article , but if you have some thing totally independent and not using entity framework , it will be greate
Comment posted by XYZ on Monday, April 21, 2014 5:29 AM
jjgkf

Post your comment
Name:  
E-mail: (Will not be displayed)
Comment:
Insert Cancel