POCO class, Entity Framework in Enterprise Applications
Often, programmers struggle with using Plain Old CLR Objects in enterprise applications. This article and the related articles in this section attempt to demystify using these classes while developing enterprise applications. POCO is an abbreviation for Plain Old CLR Objects. This class does not inherit functionality of any specific framework or technology. It is a simple public class and just contains properties and methods. These methods do not implement persistent logic such as saving and retrieving data from the database. This is the reason why we call these classes as Persistence Ignorant classes.
This class can be written in any .NET supported language such as C# and VB.Net, and can be created manually or using templates provided by Microsoft.
Each class is also referred to as domain object because it implements the domain logic of the application. Each method of the class implements validations and business logic and not the persistence logic of the application. This difference is important.
Earlier to the introduction of Entity Framework technology, we were used to developing a Business Layer using plain classes and Data Access Layer (DAL) based on ADO.Net technology. This same plain class which we have been using in all our applications till now, becomes the POCO class in Entity Framework. But with a difference. The difference is these classes do not implement persistent logic whereas the regular classes contain methods which implement persistence logic along with validations and business logic. So, do not think that this is a new feature, instead it is an existing feature and is supported in EF 4.
Enterprise applications are usually developed on multi-tier architecture pattern. In a multi-tier architecture pattern, the application is divided into Presentation layer, Business layer and Data access layer and Data layer (database).
Where do Entity framework and POCO fit in the Multi-Tier application?
Simply put, Entity Framework becomes the DAL of the multi-tier application. We have discussed in the article - Create entity data model using ado.net entity framework designer in visual studio that EF generates the EDM from the database. The EF and the EDM become a part of the DAL.
We know that, in a multi-tier application, the BL and PL should not be aware of DAL. You must also be knowing that classes are generated when we use O/RM tools such as Entity Framework or LINQ to SQL. The generated classes are aware of their persistence, which in simple words means that the classes know how to save and with which data store (data store can be - database or web service, XML file or memory object) the application is interacting. If we use EF generated classes to implement business logic of the applictaion, these classes will be aware of EF. And also, these classes are persistence dependant. So, these classes cannot be used for developing enterprise applications.
On the other hand, POCO classes are persistent ignorant which means that they are not aware of where and how to save data. These classes will make use of an available persistent infrastructure. These classes implement only the domain business logic of the application. You may be wondering by now, where should we write persistent methods. The answer is repositories. If we start using these classes with repositories, we can appreciate the power of Plain Old CLR Objects.
Now that we know where EF and these classes fit into an enterprise application, let us try and understand the advantages of using these classes in enterprise applications.
Briefly, the advantages are:
We can always replace the data access technology from EF with any other data access technology. We need not change or rewrite the Business Layer and Presentation Layer. By doing this, we reduce the dependency between layers.
Suppose, we want to convert the business logic using these classes in a web service, we can easily do it.
I recommend that if you are developing enterprise applications using EF, better use POCO classes in the application. You can refer this book titled: Develop ERP software to learn how to develop BL using simple classes and DAL using ADO.Net technology.
Ultimately, these classes need to use some persistent infrastructure to persist themselves into the database. To use the EF as the persistent infrastructure, we have to follow a few rules while creating these classes.
One additional benefit we get by using this technology is that passing them with data between layers becomes easy because of its light weight and can be easily serialized and deserializerd.
Some programmers prefer to use DTOs (Data Transfer Objects) with these classes to pass data between layers. They feel that when POCOs are used to pass information between layers, they become heavy which is unnecessary. So, they use DTOs which are also classes. The main difference between DTOs and POCOs is that DTOs do not contain any methods. They just contain public members. However, my personal preference is to use these classes without using DTOs, to pass data between layers. This is because these are lightweight objects, serializing them and sending data through them is also easy.
Recently, Microsoft added new functionalities into EF. These functionalities are tracking changes entities(POCO), Lazy Loading and fixing up relationships.
The following code defines a POCO class of a Customer.
Observe that, the word virtual is added for every property in the class. Why we do this is discussed in the coming articles.
The final conclusion is that the Microsoft has built required functionality into Entity Framework for us to develop enterprise applications.
This class can be written in any .NET supported language such as C# and VB.Net, and can be created manually or using templates provided by Microsoft.
Each class is also referred to as domain object because it implements the domain logic of the application. Each method of the class implements validations and business logic and not the persistence logic of the application. This difference is important.
Earlier to the introduction of Entity Framework technology, we were used to developing a Business Layer using plain classes and Data Access Layer (DAL) based on ADO.Net technology. This same plain class which we have been using in all our applications till now, becomes the POCO class in Entity Framework. But with a difference. The difference is these classes do not implement persistent logic whereas the regular classes contain methods which implement persistence logic along with validations and business logic. So, do not think that this is a new feature, instead it is an existing feature and is supported in EF 4.
Enterprise applications are usually developed on multi-tier architecture pattern. In a multi-tier architecture pattern, the application is divided into Presentation layer, Business layer and Data access layer and Data layer (database).
Where do Entity framework and POCO fit in the Multi-Tier application?
Simply put, Entity Framework becomes the DAL of the multi-tier application. We have discussed in the article - Create entity data model using ado.net entity framework designer in visual studio that EF generates the EDM from the database. The EF and the EDM become a part of the DAL.
We know that, in a multi-tier application, the BL and PL should not be aware of DAL. You must also be knowing that classes are generated when we use O/RM tools such as Entity Framework or LINQ to SQL. The generated classes are aware of their persistence, which in simple words means that the classes know how to save and with which data store (data store can be - database or web service, XML file or memory object) the application is interacting. If we use EF generated classes to implement business logic of the applictaion, these classes will be aware of EF. And also, these classes are persistence dependant. So, these classes cannot be used for developing enterprise applications.
On the other hand, POCO classes are persistent ignorant which means that they are not aware of where and how to save data. These classes will make use of an available persistent infrastructure. These classes implement only the domain business logic of the application. You may be wondering by now, where should we write persistent methods. The answer is repositories. If we start using these classes with repositories, we can appreciate the power of Plain Old CLR Objects.
Now that we know where EF and these classes fit into an enterprise application, let us try and understand the advantages of using these classes in enterprise applications.
Briefly, the advantages are:
We can always replace the data access technology from EF with any other data access technology. We need not change or rewrite the Business Layer and Presentation Layer. By doing this, we reduce the dependency between layers.
Suppose, we want to convert the business logic using these classes in a web service, we can easily do it.
I recommend that if you are developing enterprise applications using EF, better use POCO classes in the application. You can refer this book titled: Develop ERP software to learn how to develop BL using simple classes and DAL using ADO.Net technology.
Ultimately, these classes need to use some persistent infrastructure to persist themselves into the database. To use the EF as the persistent infrastructure, we have to follow a few rules while creating these classes.
One additional benefit we get by using this technology is that passing them with data between layers becomes easy because of its light weight and can be easily serialized and deserializerd.
Some programmers prefer to use DTOs (Data Transfer Objects) with these classes to pass data between layers. They feel that when POCOs are used to pass information between layers, they become heavy which is unnecessary. So, they use DTOs which are also classes. The main difference between DTOs and POCOs is that DTOs do not contain any methods. They just contain public members. However, my personal preference is to use these classes without using DTOs, to pass data between layers. This is because these are lightweight objects, serializing them and sending data through them is also easy.
Recently, Microsoft added new functionalities into EF. These functionalities are tracking changes entities(POCO), Lazy Loading and fixing up relationships.
The following code defines a POCO class of a Customer.
Observe that, the word virtual is added for every property in the class. Why we do this is discussed in the coming articles.
The final conclusion is that the Microsoft has built required functionality into Entity Framework for us to develop enterprise applications.