Introduction
Introduction and goal
When new technologies are introduced, one of the biggest business challenges is migrating current projects to new technologies with the least effort. I am sure scratch development is not always a preferred option from the business investment point of view. One of the new technologies which is talked most about is LINQ. This article will focus on how we can convert existing .NET classes into LINQ enabled classes.
LINQ is a uniform programming language which basically takes old .NET classes to a much improvised level. It brings down the complexity of business classes by using LINQ queries. In this article, we will touch base on how we can leverage and migrate our old .NET classes to make them LINQ enabled. LINQ has much more benefits than what I just talked; in case you are not aware of the basics, you can read about it here: LINQNewbie.aspx.
Here’s my small gift for all my .NET friends, a complete 400 pages FAQ ebook which covers various .NET technologies like Azure, WCF, WWF, Silverlight, WPF, SharePoint, and a lot more: http://www.questpond.com/SampleDotNetInterviewQuestionBook.zip.
Disclaimer: Do not blast me…
The conclusion which I have drawn here is based on a project which was migrated. The project had hardly 15 classes and they where well written. I am really not sure how this will work for projects having a huge number of classes. I will be working on this migration project for 6 months more so any more challenges or issues I face will be updated in this article.
So please do your home work before you start implementing.
Simple .NET class
Here’s a simple .NET customer class which has three properties: Id, CustomerName, and Customercode. We will look into how we can migrate this .NET class into a LINQ class without touching the core logic.
public class clsCustomer
{
private int _intCustomerId;
private string _strCustomerName;
private string _strCustomerCode;
public int CustomerId
{
set
{
_intCustomerId = value;
}
get
{
return _intCustomerId;
}
}
public string CustomerName
{
set
{
_strCustomerName = value;
}
get
{
return _strCustomerName;
}
}
public string CustomerCode
{
set
{
_strCustomerCode = value;
}
get
{
return _strCustomerCode;
}
}
}
The core of the approach: XML mapping
LINQ provided attribute based XML mapping. So you can have your pure .NET classes and you can define the LINQ mapping in an XML file. The LINQ engine can then read the mapping from the XML file and apply it to your simple .NET classes.
The XML file
Below is my XML file where I have defined my mappings of table columns with class properties, database names, table name, and class types.
="1.0"="utf-8"
<Database Name="TstServer" xmlns="http://schemas.microsoft.com/linqtosql/mapping/2007">
<Table Name="dbo.Customer" Member="WebAppMappingXML.clsCustomer">
<Type Name="WebAppMappingXML.clsCustomer">
<Column Name="CustomerId" Member="CustomerId" />
<Column Name="CustomerName" Member="CustomerName" />
<Column Name="CustomerCode" Member="CustomerCode" />
</Type>
</Table>
</Database>
To bind the XML mapping with the simple .NET class, we need to first create the XMLMappingSource object as shown in the below code snippet.
XmlMappingSource xms = XmlMappingSource.FromUrl(physicalPath + "Mapping.xml");
We need to pass the XMLMappingSource object to the DataContext class as shown in the below code snippet:
DataContext objContext = new DataContext(strConn, xms);
Finally, we can get the table and loop through the entity objects:
var query = from customer in objContext.GetTable<clsCustomer>()
select customer;
foreach (var item in query)
{
Response.Write(item.CustomerCode + "<br>");
}
Applying a Stored Procedure
In case you have Stored Procedures in your project, you can use a Function XML element to define your Stored Procedure name in the XML file. The client code does not change for binding the DataContext and XMLMappingsource objects.
="1.0"="utf-8"
<Database Name="TstServer" xmlns="http://schemas.microsoft.com/linqtosql/mapping/2007">
<Table Name="dbo.Customer" Member="WebAppMappingXML.clsCustomer">
<Type Name="WebAppMappingXML.clsCustomer">
<Column Name="CustomerId" Member="CustomerId" />
<Column Name="CustomerName" Member="CustomerName" />
<Column Name="CustomerCode" Member="CustomerCode" />
</Type>
</Table>
<Function Name="dbo.sp_getCustomerCode" Method="getCustomerByCode">
<Parameter Name="CustomerCode" Parameter="" />
<ElementType Name="clsCustomer" />
</Function>
</Database>
Advantages and disadvantages of the approach
First let’s start with all the goodies.
- You do not need to change your core .NET classes. There is complete XML isolation between your core .NET classes and LINQ engines.
- You can exploit the LINQ query and minimize your business object logic complexity.
- Your database classes are completely removed and replaced by the LINQ data context. This minimizes a lot of coding in the DAL classes.
Bad things:
- Sometimes the effort invlved in this migration can be more than that for building from scratch.
- You need to write complicated XML files by hand. We did not try SQLMETAL or other tools. Probably you guys can try it out to remove this disadvantage.
- Classes having relationships need to be replaced by
EntitySet and EntityRef. It’s a bit tricky and can change your collection interfaces.
For further reading do watch the below interview preparation videos and step by step video series.
