Jimmy Nilsson on LINQ to SQL
Recorded at:
- Share
-
- |
Read later
My Reading List
00:09:09 video length
Bio Jimmy Nilsson is co-founder and CEO of the Swedish consulting company factor10. He has written numerous technical articles and two books, including 'Applying Domain-Driven Design and Patterns'. He has also been training and speaking at conferences, but above everything else, in his own words, he is a developer with twenty years of experience. Visit Jimmy's blog at http://JimmyNilsson.com/blog/.
I am Jimmy, I am from Sweden and someone told me yesterday I had only 2 errors and one is that I like test driven development and the second is that I am from Sweden. I think having only 2 errors is good. I have been a developer for 20 years and I am into domain driven design and Agile stuff.
2. Can you introduce the audience to LINQ-to-SQL?
Microsoft has created a new framework for integrating queries into C# and Visual Basic. LINQ to SQL is one flavor. You could say it's for creating queries sent to the database, to a large extent, and it's also an object relational mapper, although a simple one. This is Microsoft's first attempt to releasing an object relational mapper. There were a couple of tries in the past history, but it didn't happen before, but I think it is going to happen this time.
3. What makes this effort better than previous efforts towards ORM and .NET?
First of all LINQ is a beautiful language in my opinion. I've tried to create a universal query language in the past and when I compared my effort with LINQ, my try was horrible. LINQ is beautiful in my opinion. So being able to use LINQ as the query language for the Object Relational Mapper is great. And there were other mappers that were quite simple to get started with, a small thing, easy to grasp, easy to get started with. And I am especially happy by this because I think this will be an eye opener for lots of .NET developers to get started with domain driven design.
4. Weren't all .NET developers working with table abstractions previously?
I think that is very common still. In the .NET community it's quite common to only use what Microsoft creates. Not many are going to use open source alternatives. So, all of a sudden lots of developers will see a new way of working with data and that is very exciting for me.
Actually the main problem I think is that it doesn't support using value objects in the domain model. That is something I've grown extremely fond of in later years. I am using lots of value objects encapsulating small concepts in the domain model. Then making those concepts easy to test on their own and reusable and intention revealing. I can't use them in LINQ to SQL and that's a really big problem, I think. Except for that there are a couple of minor things of course and there are some small problems with the persistence ignorance property. I could live with that. But not having value objects support, that is hard to live with. Especially for me, coming from domain driven design.
6. Is there a work-around to simulate value object support in Linq?
Yes I've created an ugly one. Fortunately, I can load value objects on demand and store them in simple fields, but unfortunately then the querying will be hurt also. I spoke to Microsoft about it yesterday and they had some ideas. Perhaps they or someone else will solve it by going into the expression tree to deal with this problem, but we don't want to spend too much time with workarounds. We'd like to focus on the domain, so I don't know at the moment, what will happen.
7. What is the relationship between LINQ-to-SQL and the Entity Framework?
The entity framework was created by another team and they are working quite hard on that right now. I don't know too much about it, but my impression is that the entity framework is a huge thing and LINQ-to-SQL is a small graspable thing. Both are mostly coming from the database side instead of coming from the domain driven side. Perhaps, I think, the entity framework is even worse in that respect. It's not at all about persistence ignorance at the moment, as I understand it. I like LINQ to SQL since it's so small and simple.
I have to say this. And I really believe that people should read up on domain driven design. I think that is great advice for people that haven't been using rich domain models in the past. Otherwise, it's too easy to go for an anemic domain model which only has the cost without the benefits. Not putting any behavior into the domain model and only getting this mapping problem is one problem you will encounter otherwise. Another one is to create a domain model where everything is connected to everything, a kind of ball of mud. So, I think domain driven design really helps in getting started, in a nice way.
9. How would you compare LINQ-to-SQL to Hibernate?
Hibernate is a much more mature and a more competent solution, I would say. You can deal with more complex mapping. For example, I've been working a lot with Hibernate and it has been working great for me. If you are already using Hibernate then I don't think you would move to Linq-to-SQL. If you haven't been trying Hibernate to this date then probably Linq-to-SQL is a great start for you. There is work also going on to create Linq-to-Hibernate as one way of getting the query language on top of a great mapping engine.
10. What is your favorite computer book?
My favorite computer book is the book by Eric Evans: "Domain driven design". It's like poetry I think. It's not just great content, but you can read it many times and it reads like poetry.
Re: Lost comments
by
James Vastbinder
-james
Re: Lost comments
by
Stefan Wenig
where(equals(myAlias.myMemberVariable, whatever))
(from one of your test cases)
because I think without any quotation mechanism (which java does not have), you cannot.
Re: Lost comments
by
Thomas Mueller
class Product { String name; }
Then when the product is initialized:
Product p = alias(Product.class);
a new String instance is assigned to p.name (new String()). Then when from(p) is called, p is added to the list of alias objects, and all it's members ('name'; using reflection) are added to a identity hash map. Then when you call equal(p.name, ...), the engine checks in the identity hash map what objects are passed. So you could even do this (not that you should):
Product p = alias(Product.class);
String pName = p.name;
from(p).where(equal(pName, "Jones")).select(pName);
Regards,
Thomas
Re: Lost comments
by
Stefan Wenig
Also, you'd have to do a very deep initialization to make queries like equal (p.Customer.Name) possible, which is rather unlikely.
You require a default constructor, which you actually call. Creating instances and setting their members to arbitrary values might have side effects though, especially in ORM situations that quaere is probably targeting (automatic enlistment in unit-of-work, range checking...).
So you need to make a lot of stuff in your apps and frameworks fit the quaere model, application developers need quite some knowledge so they can actually write working queries without trial-and-error, you have very limited compile-time support, and the syntax is quite hard to read compared to LINQ. I think you're not doing yourself a favor insisting that you provide 95% of LINQ.
But still, clever! I don't think you could go much further with Java.
Hibernate and other ORMs vs. LINQ
by
Duraid Duraid
Re: Lost comments
by
Thomas Mueller
Yes, unless using dirty tricks like Integer.MIN_VALUE+x. -10%.
> very deep initialization
I am not sure, but I don't think this is a big problem. You could define a configuration option how deep to initialize. If this value is too low, the query would throw a NullPointerException. -1% (in my view)
> You require a default constructor... Creating instances and setting their members to arbitrary values might have side effects
The O/R mapping tool needs to do that as well. Theoretically it could be a proxy class (a class that extends the class; created at runtime).
> application developers need quite some knowledge
At least they can debug everything - it's pure Java. After you understand how it works there is little magic.
I agree it's not 95%. Let's say 84% ;-)
> Hibernate and Linq
Hibernate is not LINQ: it is DLINQ (dynamic LINQ). As far as I know, the current version of DLINQ is not as easy to use as Hibernate.
Re: Lost comments
by
Stefan Wenig
- counting integers (globally, interlocked? what do you do at the first overflow - hope the old ones aren't needed? or do you simply require people's classes to use Integer instead of int?)
- defining initialization depths (and thus requiring query programmers to keem them in sync with the depth they actually use - otherwise runtime error or waste)
- ignoring possible side-effects (even a subclass proxy would have its base class constructor called, unless you can prevent constructor calling alltogether, which your statemtent about O/R tools needing to do this as well seems to negate. I'd wonder how Java handles deserialization then, though)
- even then, those side effects could be perfectly welcome for actual objects (e.g. enlisting objects) but not for objects that were never supposed to actually exist (aliases), so the comparison with ORMs doesn't quite fly.
Add to this the ugly syntax of .where(test(A, SMALLER, B)) instead of where a < b, or the set-syntax in .select instead of anonymous types, and even 84% seem to be way off in terms of language integration.
If I were a Java developer, I'd consider using it, because all those drawbacks might be better than having that strong old separation between static code structure and dynamically parsed query _strings_. But still, percentage-wise, this is a brave statement.
BTW:
Afaik, DLINK refers to Data-LINQ, an old name for what was to become LINQ 2 SQL. LINQ 2 SQL is very easy to use, but quite limited in its ORM capabilities. Compared to NHibernate, it looks like an attempt to take a query engine and build an ORM around it as an afterthought. But then, it's been made for a certain kind of problems, and if you don't object to the strong relationship to the SQL Server product, it's a nice library. Comparing LINQ itself to NHibernate makes no sense, because LINQ is a language feature which HNibernate is going to support too. You could compare it to HQL though.
Re: Hibernate and other ORMs vs. LINQ
by
AVINASH HOTA
Re: Hibernate and other ORMs vs. LINQ
by
Stefan Wenig
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think