locked
Linq changes my architecture RRS feed

  • Question

  • Dear reader,

    a while ago, I learnt LinQ. I love it and I made two observations

    First:

    My code shrinked a lot :-))   Many for-loops are substituted by single line "LinQ-Enumerable-Iterations-Statements"

    Second (thats the reason for this post):

    Before using LinQ, I filled in my Parameter/Configuration-Data into classes at startup and passed them around in my class/object-hierarchy.

    But now, due to simplicity with usage of LinQ, I pass around XElements-Subtrees (with my parameters) directly within my object-hierarchy, instead of parameter-classes. It's easy, no parameter classes at all. It's fast for development, I just insert a new XElement in my XML-Configuration and I directly have it deeply nested somewhere in a class where I need it. Wowww...

    But it somehow makes me curious - I feel something is wrong with this approach. Do you know what? E.g. I loose type-safety. But what else is lost?

    Thursday, January 30, 2014 1:50 AM

Answers

  • A "class" is a structure that contains methods.  Structues came long before classes where developed.  You XML is simply a structure with no build in methods.  So we are comparing using structures with XML elements (not class with XML elements).  Any methods you are using are the built in LINQ and XML methods.

    XML is parsing strings.  It is using late binding. Using classes will use early binding.  The advantage of early binding methods is that more of the functionality is performed by the compiler while late binding is performed at runtime.  So early binding noramally will run quicker.  Some people may say the XML classes are more efficient because they are optimized better and these people have a good point.  Most of the Net library functions are written in C++ with unmanaged code which is much more efficient than running C# managed code.  So using an XML library function using C++ may be a great solution.


    jdweng

    Thursday, January 30, 2014 3:45 AM