Some Problems with ORM

So all this dynamic, runtime SQL generation stuff sounds great, right? Not so fast: ORM has several serious drawbacks. The first of these is performance, as you’re going to encounter a slowdown any time you bring reflection into the equation and start dynamically generating SQL. ORM will never be as fast as rolling your own: there’s no substitute to being able to hand-tweak your stored procedures and pre-compile all of the data access logic. Another drawback is that ORM doesn’t deal well with extremely complex databases. When designing complex databases with a lot of constraints and relationships spanning several tables, it’s often necessary to include intermediary tables to link various entities together that is great from a RDBMS standpoint, but doesn’t translate all that well to an object-oriented environment. This can lead to obtuse and difficult to understand auto-generated classes. Keep in mind that RDBMS and object-oriented environments are fundamentally different, and each includes its own set of design and performance considerations. What works in one environment is not necessarily optimal for the other environment. That being said, the upside to ORM in terms of maintainable, clean, and easy to understand code can be quite compelling, provided that it’s used correctly.

ADO.NET Entity Framework in .NET 3.5

LINQ in .NET 3.5

How do they do it? LINQ. It stands for Language INtegrated Query and Microsoft wants it to be THE way that you sift through data in the .NET framework. Its structure will be immediately familiar to anyone with experience writing SQL statements and it marries the simple yet powerful query syntax of SQL to the strong typing of an object-oriented language. The real kicker, however, is that it’s not limited to relational data: anything that implements the IEnumerable and IQueryable interfaces can be used with LINQ. Here’s a quick example so that you can get an idea of what it’s capable of:

It’s just a simple search of a generic string list instance for elements that contain the letter “n”. Whereas before you would have had to accomplish this imperatively, that is, you would have had to write code to iterate over the collection and drive the search, you can now accomplish the same thing declaratively. Basically, you’re stating what you want to do instead of how to do it. While the syntax takes some getting used to, this approach is inherently less error-prone. It also bears mentioning that Intellisense is in full effect in the above sample, so you lose none of the “ease of use” features of Visual Studio when you employ LINQ.

.NET as it had evolved has come up with different API to read and write XML data. If you are using .NET 3.0 and lower version you will have to use XMLDocument aka the classic DOM API. With .NET 3.0 Microsoft had launched Language Integrated Query(LINQ) and with this came one of the feature name the LINQ to XML.

LINQ to XML has a simple model for building XML documents by hand. Whether it be XML sources from a stream or file, or XML created on-the-fly in code there are only a few important types to know and understand. The main ones used in everyday activities are XDocument, XElement and XAttribute.

In this article we will talk about XDocument and XMLDocument.

Lets consider the following test data for our article

<root>

<child id=’123′/>

<child id=’234′/>

…

</root>

Reading the XML

XmlDocument.Load

XmlDocument.Load was the cleanest and easiest to understand. It is necessary that you must know XPath, although the fact is I like XPath. XmlDocument does have some security concerns with XPath injection. Here is how we code to load a document

private static void XmlDocumentReader(string fileName) {

XmlDocument doc = new XmlDocument();

doc.Load(fileName);

XmlNodeList nodes = doc.SelectNodes(“//child”);

if (nodes == null) {

throw new ApplicationException(“invalid data”);

}

foreach (XmlNode node in nodes) {

string id = node.Attributes["id"].Value;

ProcessId(id);

}

}

Another way to query a single node is given below

XmlDocument doc = XmlDocument.Load(fileName);

XmlNode node = doc.SelectSingleNodes(“/root/child[@id=’123’")

LINQ to XML

LINQ to XML was also very easy to read and understand code. XDocument.Load does read the whole document into memory before returning. Due to feature of Lambda expression it has become very easy to traverse the xml document. The query syntax is easier than XPath or XQuery for developers who do not use XPath or XQuery on a daily basis. Here is the code I used to load and search the document:

private static void XDocumentReader(string fileName) {

XDocument doc = XDocument.Load(fileName);

if (doc == null | doc.Root == null) {

throw new ApplicationException("invalid data");

}

foreach (XElement child in doc.Root.Elements("child")) {

XAttribute attr = child.Attribute("id");

if (attr == null) {

throw new ApplicationException("invalid data");

}

string id = attr.Value;

ProcessId(id);

}

}

Another way to query a single node is given below

var xd = XDocument.Load(fileName);

var domQuery =

from c in xd.Descendants("child ")

where (string)c.Attribute("id") == "123"

Writing a new XML

Both the method almost looks similar.

XmlDocument

XmlDocument xmlDoc = new XmlDocument();

// Write down the XML declaration

XmlDeclaration xmlDeclaration = xmlDoc.CreateXmlDeclaration("1.0","utf-8",null);

// Create the root element

XmlElement rootNode  = xmlDoc.CreateElement("root");

xmlDoc.InsertBefore(xmlDeclaration, xmlDoc.DocumentElement);

xmlDoc.AppendChild(rootNode);

// Create a new <child> element and add it to the root node

XmlElement parentNode  = xmlDoc.CreateElement("child");

// Set attribute name and value!

parentNode.SetAttribute("ID", "01");

xmlDoc.DocumentElement.PrependChild(parentNode);

LINQ  to XML

XDocument doc = new XDocument(

new XDeclaration("1.0", "utf-8", "yes"),

new XElement("root",

new XElement ("child", new XAttribute("id", "01")

)

);

Manipulating XML Data

XmlDocument

Here we have to struggle with manipulating the xml data. First take help of XPath to select the node and then use replace node to update it. Or use the feature of delete node and insert new node. Code is given below

XmlDocument doc = new XmlDocument.Load(fileName);

//Select the cd node with the matching title

XmlNode oldCd;

XmlElement root = doc.DocumentElement;

oldCd = root.SelectSingleNode("/root/child[id='1']“);

XmlElement newCd = doc.CreateElement(“child”);

newCd.SetAttribute(“id”,2);

root.ReplaceChild(newCd, oldCd);

//save the output to a file

doc.Save(fileName);

LINQ  to XML

Here the code is very simple to write and understand. The coding time is also very less.

var xd = XDocument.Load(fileName);

var domQuery =

from c in xd.Descendants(“child “)

where (string)c.Attribute(“id”) == “123″

domQuery.Attribute(“id”).Value = 1

xd.save(filename)

Conclusion

Overall speaking both the API’s are equally powerful. However LINQ has made it little bit easier for developer to work with XML Data. I would say if you are using .NET 3.5 and higher you should rather go with LINQ To XML.