ReDLinq Mapping

time to read 3 min | 550 words

Dinesh has a post where he talks about the relative advantages and disadvantages of ORM mapping schemes. There seems to be quite a bit of noise about DLinq only supporting attribute mapping in the PDC.

Here is my take on the subject:

Whenever possible, make mapping via attributes possible. The ability to quickly tag a class with attributes and have a workable mapping is very important in most design scenarios, where you want maximum flexibility in changing the mapping. Even though that a compiler can't catch logical mistakes in the mapping, there is a certain class of mistake thati it would catch, so it's good to have it.

Here are Dinesh' take on the  advantages of external mapping:

  1. Same classes can be mapped to multiple data models using different mapping files
  2. Avoids clutter in source code, especially in case of complex mapping
  3. Hides database-specific information from users of object model
  4. Some schema changes can be handled without recompilation (IMO, the class of changes that can be handled is often exaggerated)

I agree that 1 and 3 are good points for extenral mapping, but I feel that they can be hanlded via a secondary mapping which is external to the object while keeping most of the mapping in code. I wrote several applications using NHibernate, which uses XML mapping extensively. It was often a pain to trace the difference between the mapping and the model. The errors can be subtle and hard to track down.

I completely disagree with the advantanges of both 2 and 4. First, clutter in code? Those classes are the gateway to the database, the last thing I want to see is people starting to think of them like normal objects: customers.HugeOrdersCollection.Count - (Load all the orders to memory and return their number, prohibitely expensive operation). The idea in ORM is to make it easier to work with the database, not to divorce all knowledge of its existance. I know that this isn't what Dinesh suggested, but that is the thought behind removing "clutter" from the code.

About changing the schema without recompiling. Care to give me a real scenario where you would be changing a live database where you don't have to recompile? I can't think of any non-really-trivial changes that you can make that wouldn't force you to change code.

More posts in "Re" series:

  1. (23 Jun 2021) The performance regression odyssey
  2. (27 Oct 2020) Investigating query performance issue in RavenDB
  3. (27 Dec 2019) Writing a very fast cache service with millions of entries
  4. (26 Dec 2019) Why databases use ordered indexes but programming uses hash tables
  5. (12 Nov 2019) Document-Level Optimistic Concurrency in MongoDB
  6. (25 Oct 2019) RavenDB. Two years of pain and joy
  7. (19 Aug 2019) The Order of the JSON, AKA–irresponsible assumptions and blind spots
  8. (10 Oct 2017) Entity Framework Core performance tuning–Part III
  9. (09 Oct 2017) Different I/O Access Methods for Linux
  10. (06 Oct 2017) Entity Framework Core performance tuning–Part II
  11. (04 Oct 2017) Entity Framework Core performance tuning–part I
  12. (26 Apr 2017) Writing a Time Series Database from Scratch
  13. (28 Jul 2016) Why Uber Engineering Switched from Postgres to MySQL
  14. (15 Jun 2016) Why you can't be a good .NET developer
  15. (12 Nov 2013) Why You Should Never Use MongoDB
  16. (21 Aug 2013) How memory mapped files, filesystems and cloud storage works
  17. (15 Apr 2012) Kiip’s MongoDB’s experience
  18. (18 Oct 2010) Diverse.NET
  19. (10 Apr 2010) NoSQL, meh
  20. (30 Sep 2009) Are you smart enough to do without TDD
  21. (17 Aug 2008) MVC Storefront Part 19
  22. (24 Mar 2008) How to create fully encapsulated Domain Models
  23. (21 Feb 2008) Versioning Issues With Abstract Base Classes and Interfaces
  24. (18 Aug 2007) Saving to Blob
  25. (27 Jul 2007) SSIS - 15 Faults Rebuttal
  26. (29 May 2007) The OR/M Smackdown
  27. (06 Mar 2007) IoC and Average Programmers
  28. (19 Sep 2005) DLinq Mapping