I keep getting a lot of questions about whether DLinq is for data objects or for business objects. There is no shortage of advice - both good and bad about what one should and should not do with DLinq.
Here, I want to briefly describe what we had in mind. It might not match someone's specific ideas about the terms "data objects" or "business objects" so hold your flame and send your feedback.
Here is how we approached the design:
These choices may not solve every object persistence problem and satisfy every taste. They were not meant to. We wanted something that made sense to a general .NET developer who is not steeped in ORM esoterica and expects something that is dependable and easily understandable. There were many times when we discarded flexible designs that had too many nuances and required too much expertise to clearly understand. We believe that the average .NET developer is trying to solve a business problem, not write another persistence framework on top. We wanted the existing intuition about CLR data model and CLR objects to be your friend and worked on minimizing additional concepts. As a result, there may not be lots of ways to do one thing. In some cases, there may not be any direct way to do exactly what you want to do. That, is "by design".
Some day, I hope to write more about the approach of C# design meeting (chaired by Anders Hejlsberg and attended regularly by colleagues like Matt Warren, Erik Meijer, Mads Torgersen and Cyrus Najmabadi). That is where LINQ and DLinq were cooked. But I must stop here - I have to run to catch a flight.