Paul Wilson's .NET Blog

"...But you've already marked your Customer class with the attribute "Table(Name = 'Customers')", not too mention all the Column attributes -- so why isn't the attribute enough to make it clear what "Customers" refers to?"

Perhaps one might use two databases at once? What's wrong with that?

About being tied to MS SQL: I don't think that it will be tied to anything at the end (not sure what's the situation right now).

But look on the bright side: it supports read after save and it supports saving all context at once.

:-)

I think you'll find with a closer look at the docs that even using multiple databases doesn't require that additional complexity. And while I hope you're right that it won't be tied to MS Sql in the end, so far experience has taught us otherwise -- and as others have already pointed out (and me also a long time ago), an attribute based system makes it much harder to support multiple databases in many real-world cases. Finally, who doesn't support read after save, and you already know that I consider saving an entire context to be a questionable practice in most cases, but to each his own.

You said:

why should I have to say "from c in db.Customers select c" when I could just "from Customers" or have a strongly typed Get accessor...

In actuality, you can do foreach(var c in db.Customers).

You do not have to use select if you want all the customers. Table<Customer> derives from IEnumerable<Customer>.

That's good to know, although in that case it doesn't look like there's any way to define a default sort order that many of us provide.

Would anyone plase actually read the overview document by Box and Hejlsberg? Quote:

"Full-blown object/relational mapping could also take advantage of this core query capability for users wanting that functionality."

Dlinq is not MEANT to be a full ORM. It is strongly typed querying against databases, that is it. I really don't believe that the main scenario they anticipate here is that you actually use instances of the classes on which you define the mapping as your business entities. They are just used to give you strongly typed access to a specific DB, that is it. What type of object you actually get from a query is a totally different question, and one Dlinq does not enforce anything on you. You can just project into an anonymous type, or if you want into objects that are your business entities. Its up to you.

It may not be intended to be a "full" ORM, but it is nonetheless an ORM. My own ORM also does not try to have every feature, but that's because it is targetted at simplicity and the most common 90-95% scenarios -- and I'm stating that DLinq fails in those goals too, and that after years of effort and already having had lots of feedback.

Now I have read that document and seen that quote, but I believe you're failing to see that anyone attempting to build a "full ORM" on top of DLinq will still be limited by its basics. How will you build something on top of it without first defining these attribute based entities, and how will you add support for other databases if DLinq does not do so?

No, I'm sorry, but DLinq is an O/R Mapper although it does appear they don't want to call it that -- maybe they're afraid people will then discover there are others once they are familiar with that term. :) And if someone seriously believes its not an ORM, then do tell what it is?

You may want to enter your feedback at http://blogs.msdn.com/danielfe/archive/2005/09/15/467239.aspx

Hi Paul,

"I think you'll find with a closer look at the docs that even using multiple databases doesn't require that additional complexity."

But how would you specify from which database you want read from?

"And while I hope you're right that it won't be tied to MS Sql in the end, so far experience has taught us otherwise "

Yes and no. Look at ADO.NET for example.


"-- and as others have already pointed out (and me also a long time ago), an attribute based system makes it much harder to support multiple databases in many real-world cases."

Attributes are just attributes. This doesn't mean that one can use some sort of mapping file, too.

"Finally, who doesn't support read after save, and you already know that I consider saving an entire context to be a questionable practice in most cases, but to each his own"

:-)

I think that David has a good point here. DLinq alone is a querying engine (sort of). ORM is done through DataContext which is a sepearate beast.

I have my own ORM also so when I heard about dlinq I was also wondering what place was left in the world for it. I agree with you that linq is great but dlinq is a poor substitute for a real ORM.

I think you're overstating the importance of the fact that 99% of developers never use anything but what MS gives them. First off, MS is certainly giving them something much better than they've had before, so even for those people, dlinq is a step up.

But more importantly, for those of us who *do* care about the features MS left out, the infrastructure invented to support dlinq pretty much guarantees that our own ORMs will be able to do cool stuff that's previously been unable to.

For example, right now users of my ORM have to jump through hoops to do sorting - either by declaring several gets with different sort orders, or by doing stuff like:

ArrayList people = Person.GetByAll();
people.Sort(Person.LastNameOrder);
foreach (Person person in people) {...}

secondary sorts are even more awkward.

Allowing stuff like:

var people = from p in Person.GetByAll()
orderby p.LastName, p.FirstName
select p;

is much nicer especially if it's possible to get the database to do that ordering, which I think it is (again, using the same technology developed for dlinq).

I was actually waiting for your comments on this, and you are pretty much spot on.

One more point:
One of my complaints about WinFS when introduced at PDC 2003 is that they introduced Yet Another Query Language. We've got Query Languages for WMI, MSI, SQL (and all subsets like T-SQL and PL-SQL), XPath, SNMP, and who knows what else. Now, added to the mix is Linq/DLinq/XLinq.

As a 'front-line' developer, the only usefull thing that I can hope for out of all of this is a melding of query languages while working in a .NET world.

I think you are correct when you state that because it is in the framework, this will become the defacto standard.

--

On a related note, what was more interesting to me than Linq was the idea of extension methods. To be introduced in C# 3.0, it provides a mechanism for adding functionality to existing (usually sealed) classes. Seriously cool stuff, though it should be used with care.

"On a related note, what was more interesting to me than Linq was the idea of extension methods. To be introduced in C# 3.0, it provides a mechanism for adding functionality to existing (usually sealed) classes. Seriously cool stuff, though it should be used with care."
The rest of the world calls that AOP and is generations ahead in that field compared to the .NET world, except perhaps spring.NET and some early bird weavers.

Extension methods can IMHO be used to enable AOP elements, which is great, though this can already be done transparently, now, as spring.NET shows.

For the people who think DLinq isn't an attempt to write an O/R mapper, it's my understanding that DLinq performs CRUD operations, not just retrieval. The document of DLinq for example mentions change tracking and why would anyone need changetracking if you don't save data? ;)

The DLinq document I linked to quite explicitly has persistence examples -- so that's not an open question.

http://www.lowendahl.net/showShout.aspx?id=53

Frans - Yes, I'm familiar with AOP - however, until support baked in, then it's unlikely that I will be able to use it. I don't drive such feature adoption in my organization. For me, Spring.NET (or O/R Mappers) are a tough sell. I've got a large team to convince. However, if a feature is part of the base language, then it is generally not an issue.

"How will you build something on top of it without first defining these attribute based entities, and how will you add support for other databases if DLinq does not do so?"

I think you're not looking deep enough at the technology yet. You're letting the "lameness" of DLINQ, which I somewhat agree with, blind you from what really matters.

LINQ is the base. DLINQ and XLINQ are built on top of LINQ. If you wanted to build your own ORM you don't build on top of DLINQ. You build something that is a sibling to DLINQ. You then build LINQ support for your custom ORM.

So considering your existing architecture, you essentially keep exactly what you have now for configuring and representing entities and all you do is throw out whatever mechanism you came up with for querying and replace it with support for LINQ expressions.

For example, for querying in my custom ORM implementation I have the concept of an EntityQuery, EntityQueryConditionGroup and EntityQueryCondition classes. EntityQuery is made up of multiple conditions as well as exposing sorting and paging semantics. These essentially get thrown out when I update my ORM implementation to work with link LINQ. Instead, I allow people to use LINQ and I translate the LINQ expressions into SQL statments just like DLINQ does to be as efficient as humanly possible for the backend data store I'm talking to. For example, you mentioned paging, I could be sure to issue a TOP statement to ensure I don't get back any more records than I really need. BTW, DLINQ *does* support this the same way, the expression is just a weird name which I can't remember off the top of my head.

Ultimaely I believe that once you give it some more time you'll realize that how they implement DLINQ really doesn't matter. Focus on your ORM and be very comfortable in the fact that you'll be able to integrate with the rich querying syntax smoothly into languages using your own custom LINQ expressions.

Cheers,
Drew

Hi Drew:

That I can agree with -- you are correct that I can build just on top of Linq. I guess my issue is that even though this can be really cool for my OR/M, its not enough since MS is also giving us DLinq. Why, since as you point out I can ignore DLinq? Because the vast majority of people and shops in the MS world expect you to use the MS implementation. If MS only gave us Linq then a decent minority would be willing to accept other mappers that took advantage of Linq. But once MS also gives us DLinq, then that will be what most people will use, and they will never look elsewhere or see that there is even a reason to do so. While I do really like my mapper, I know that I'll have far more clients that won't be willing to use it or any other mapper -- and since I'm a consultant far more than I am a vendor that is a big deal to me. I do think Linq is great, but I find it inexcusable that MS has worked over 5 years on OR/M and in their 3rd attempt now they have made a mess. What were they thinking?

Paul,

Yeah, I hear ya. I guess that's less of an issue for me personally since I'm not a consultant.

That said, this technology is way out there (probably 2008) and they were VERY open to feedback. If you really are worried about DLINQ's shortcomings, I highly recommend getting involved right now if you want to voice your opinions and maybe get some of the changes you'd like to see taken care of.

I'm just extremely pleased with the base LINQ technology and that our own ORM implementations will be first class citizens with respect to the language syntax. :)

Your review sounds like sour grapes to me.
If you want all customers just use:
"var q = Customers"
I don't see how you can get any more succinct than this. Inheritance will be the next feature added when they return to redmond, heck maybe in time for your MVP conference. WinFS integration with LINQ was shown at the conference.

There are several severe limitations with Dlinq right now but lets kick the tires and get them to raise the bar.

Hm,

I am heavily looking into the whole LINQ thing right now for the next generation of our EntityBroker... AND....

It looks like while we WILL support LINQ (as "ELinq"), we will NOT throw out or own stuff. Because sadly LINQ is way too limited in it's expressions. Stuff like paging, load hints can not be represented - the query syntax is just too simple.

As elegant as it is, sadly.

Just wondering if c# 3.0 is going to be released with visual studio 2005 and .net 2 in november 2005.

All this new linq stuff looks cool but i'm wondering if its worth my time to looking into this if its not getting released for another year or something.

thanks

Oh my no -- C# 2.0 will be released with VS 2005 and .NET v2.0 -- not C# 3.0. You're looking at 2007 or 2008 before C# 3.0 and .NET v3.0 comes out. PDCs are always about the next wave, not the current wave -- TechEd and other conferences are better suited for learning the current wave. So the question for you is are you preparing for 2.0 ?

As I understand it LINQ does not require a new runtime, i.e. .NET 3.0, but runs on .Net 2.0. What it does need is new compilers though. In the PDC presentations Anders Hejlsberg said they were targeting ORCAS(next release of Visual Studio after Whidbey) for those. This *probbaly* means early 2007. (http://msdn.microsoft.com/vstudio/productinfo/roadmap.aspx)

I think adding some information here might help. DLinq was designed to be an extremely low entry point into ORM and to be used as an example of how to build a LINQ enabled API. Dlinq is a preview of technology that will likely change considerably before it ships, adding or changing features based on feedback. We decided to show this technology extremely early in its design so that by the time it ships it will be the right combination for a broad customer base. However, we anticpate that other ORM vendors offering superior features will also choose to LINQ enable their products to take advantage of language integrated query. This was indeed a goal of LINQ's design, keeping the language features entirely separate from the API's.

At this point, the design of DLinq has been biased heavily toward rich query support with an API targetted toward simplicity. This has lead to trade-offs in what is available today, such as attribute based mapping declarations and a class of mapping that is not much more than one-to-one with the database. While these may not scale to the kind of applications handled by ORM's such as Paul's, they are indeed simpler to define, easier to grasp and quicker to make use of.
Still, our intention is not to leave DLinq in this state, but to advance it to include some of the more popular ORM features such as inheritance, many-to-many mapping, events, support for additional databases and so on, depending on the kind of feedback we get.

Remember, this is not a finished product nor is it even a beta. It is not a revision of ObjectSpaces, yet it is based on many lessons we learned from building both ObjectSpaces and C-Omega. We've previewed it early so you can tell us what is most important to you.

Christoffer:
While you can run the Linq preview with VS 2005, it works only by redirecting to a preview C# 3.0 compiler. It is not part of VS 2005, .NET v2.0, or C# 2.0 -- nor will it become part of that, other than a preview.

Matt:
Thank's for the explanation. Its very good, but its still extremely frustrating to keep hearing that this is just an early preview when we know MS has 5+ years experience wrapped up in O/RM. I still haven't heard anyone explain why ObjectSpaces wasn't turned into DLinq.

LINQ does not require version 3.0 of the .Net _framework_. It will work with v 2.0 of the framework.
What it does require is new compilers. The c# 3.0 compilers and VB.Net 9.0 compilers will be part of ORCAS which *may* very well be released before a version 3.0 of the .Net framework...and hopefully before 2008 ;-)

I have written a small project about LINQ and DLinq. This might an interesting read for some of you guys.

The only thing scarying me is the lack of updates to WilsonORMapper....   :)

hehe,

glad to hear you say that - I was just installing it yesterday, did some Linq for the first time over a Dlinq model I created, and I was pretty impressed.

Granted Paul, I agree, it's probably not perfect, but it's making progress and it's definitely easy to get started with.

:)

I didn't mean to knock you by the way, you've done a great job on your tool and I felt it was definitely worth the money I paid to help support it!

Paul I just blogged about a comparison between Wilson ORM (WORM) and LINQ for SQL (LINQ)

http://mikelockyer.spaces.live.com/blog/cns!D935506AB1D72BB9!132.entry

Have been having a really postive time with your ORM and my students.

Thanks

Mike

Hi Paul,

I'd be interested to learn your up-to-date opinion on LINQ to SQL. I also thought very little about DLinq when it first arrived on the radar back in 2005. However, i have to say that having experimented with the latest CPT I'm pretty impressed in general.

Cheers,

Chris.