Linq==Cool. DLinq==... what!?

Ok, everybody and his/her brother has blogged about Linq already so why not ramble some words about linq here? .

First, Linq itself. Linq is cool. It's a system to build language constructs inside C# or VB.NET. For the people who haven't waded through the .docs describing Linq in detail, you can see it as operator overloading on steroids: define your own language constructs with C#/VB.NET language constructs in a typed way, so that you can write simple queries or functions over data, which resolve to your own structures, expression trees, or to plain C#, VB.NET, whatever you can think of.

Ok, so that's cool, we can safely all agree on that.

Now, Microsoft thought... "Hey, everybody is doing that attribute based O/R mapping. Why not do it ourselves?". Together with Linq they build DLink: an attribute based O/R mapper. I couldn't believe my eyes: while every decent O/R mapper moves away from attribute based O/R mapping simply because it's not scalable beyond 1 database, Microsoft moves towards it! .

I understand the reason for attribute-based mapping in their case (meta-data in the assembly, which can directly be used by intellisense, compilers etc.) though it's not very flexible to begin with. To see this, consider a domain object, the ol' dreaded 'Customer', and that you map it on an SqlServer table. You give it a good old Guid PK, a nice boolean field 'IsGoldCustomer' which is mapped onto a bit field etc..

Then your client asks you... "You do Oracle too, right?"

You hear yourself mumble through the phone: "Sure, no problem!"

But, next day, when you're starting to work on a port to Oracle, which should be simple, you realize... mapping information inside the domain object, which contains SqlServer specific elements, isn't usable on Oracle. Why didn't you opt for a system which didn't use attribute based O/R mapping!

It's a preview of course, and there's a long road towards final code, but, take it from the field, Microsoft: attribute-based O/R mapping isn't the way to go.

12 Comments

  • "which should be simple, you realize... mapping information inside the domain object, which contains SqlServer specific elements, isn't usable on Oracle."



    Well, shouldn't the O/R mapper abstract those specific things away for you? It seems to me that a well written one should.

  • I don't agree with your conclusion that attribute based O/R will limit you... I think if you design the O/R to work with a variety of databases, or in a generic way, there won't be any problem with it.

    In fact, i think it's easier to work with attributes on objects, as it lets you see where each object maps to, rather then having to search through an xml file or some external resource.

  • It will be interesting to see how all of this turns out. I still can't believe that there's this much cool stuff in C# 3.0 and the next, greatest .NET framework, but there's no nullable type support in ADO.NET. L-A-M-E. :-)

  • Attributes don't scale well in this case, because the attributes contain database specific information: table/field names, and often type specific information.



    This therefore means that you can't use a single class for 'Customer' and use it with both oracle and sqlserver (or whatever database): in my example, in sqlserver, you can map it directly, in oracle, you've to convert the bit type and the guid, and maybe in oracle you map it to MY_TABLE.SOME_FIELD and in sqlserver you map it to MyTable.SomeField.



    Don't think lightly about this, in a lot of applications this is reality: have the current code base support an additional database, how to do that? If the O/R mapper can't deal with that without having you rewrite a lot of code, it's better to opt for another O/R mapper. It's weird that MS decides to move towards Attributes in this case, because it precisely limits the system for this reason. As they use XML for everything, it would be a better choice to use an XML file for this too, and use attributes to refer to mapping elements in the xml file if you really want the meta info in the code.



    Marius: I didn't even think of the CRU methods, indeed... I've to look closer to the specs to see if they solved that.

  • I don't have the impression that this is meant to be a traditional O/R mapper. I think all it does is give you strongly typed access to a specific database. I don't see that the objects generated by the tool from the database that hold the attributes are meant to be your business entities. They are strongly typed entry points into your database, no more. Why? Well, just think about how you proceed from there: Normally you will specify some complex DLINQ query, and at that point you don't get back objects of those mapping types, but rather anonymous types that depend on whatever query you specified. From there on it is up to you what you do with them: Push them into your business entity objects, deal with them directly, push them into XML, whatever.

  • Frans,



    You're probably one of the topmost O/R gurus out there. I think you should push your opinion upwards though other* channels.



    - SM

    *You know what I'm talking about right?

  • Hi Frans



    You mentioned in one of your posts that "Attributes don't scale well in this case, because the attributes contain database specific information: table/field names, and often type specific information."

    I am a bit confused. Is that not what LLBLGen does with Self servicing? 1 Object = 1 Table?

    1 Object with 6 Properties = 1 Table with 6 Fields?



    Or am i misunderstanding this?

  • Wayne: yes, selfservicing does that too, that's also why there's adapter, which allows you to target multiple databases without worries :). Selfservicing isn't suitable for that, as it contains the persistence info in the entities, exactly as DLinq does, and has the same limitation.

  • Hi Frans,

    I guess the ability to switch databases (e.g. from SQLServer to Oracle) is only important to a small group of people. In fact: I've never had the need to switch, nor do I know anyone who ever wanted that (but then again: I've only developed on custom made software for clients, not on retail products).



    DLinq offers a utility to generate all O/R mapping code for you (just as LLBLGen does), and I expect the tool is also capable to generate O/R mapping code targeted for Orcale in the future. So when switching databases: couldn't you just re-generate the O/R mapping code again, and ten recompile your code?



    B.t.w.: I still love using LLBLGen :)

  • "DLinq offers a utility to generate all O/R mapping code for you (just as LLBLGen does), and I expect the tool is also capable to generate O/R mapping code targeted for Orcale in the future. "

    It's likely, yes :)



    "So when switching databases: couldn't you just re-generate the O/R mapping code again, and ten recompile your code?"

    No, not if you're using a single codebase for your own code which has to target multiple databases, live. More people than you think use this feature, or have to use this feature.



    We'll see what DLinq brings in the future ;). I mainly see it as an example implementation of Linq, so more sophisticated O/R mapper engines can follow the same path.

  • I agree with other comments that ideally the O/R Mapper should abstract away vendor differences. I can't see why it should be any harder to do this with an attributed approach. Of course, the attributes must be generalized; you should never refer to bit or guid as these are physical details abstracted away by mapper.

  • "I guess the ability to switch databases (e.g. from SQLServer to Oracle) is only important to a small group of people"



    I would have to strongly disagree with this statement. You are correct in the sense that this is not a universal need for all applications, but to say that it is a rare event is an understatement. Think about government consulting, for one. Frans knows that switching from one database to another, perhaps due to switching hosting environments entirely, happens in government work (he helped me a great deal in my project switching from SQL Server to Oracle 9i :-)). I think the greater majority of scenarios lies in the need for commercial products to support a choice of database platforms. Having a single codebase for your business objects is a significant advantage, I think.

Comments have been disabled for this content.