New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
Interview
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Jimmy Nilsson on LINQ to SQL
Interview with Jimmy Nilsson by Floyd Marinescu on Jan 09, 2008 Length 00:09:09
Summary
In this interview, Jimmy focuses on LINQ to SQL and ORM. Jimmy has tried to create a similar technology to LINQ to SQL in the past, but without similar results. While LINQ to SQL is a step in the right direction, .NET still lags behind other programming languages in object-relational mapping capabilities.
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/.
In this interview, Jimmy focuses on LINQ to SQL and ORM. Jimmy has tried to create a similar technology to LINQ to SQL in the past, but without similar results. While LINQ to SQL is a step in the right direction, .NET still lags behind other programming languages in object-relational mapping capabilities.
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/.
This is Floyd Marinescu here at the JAOO Conference with Jimmy Nilsson. Jimmy can you tell us a bit about yourself?
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.
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.
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.
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.
So technically what are some of the benefits and limitations of the current LINQ-to-SQL implementation?
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.
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.
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.
What advice would you give developers on the design of the domain model and the mapping framework in their next .NET application?
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.
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.
RelatedVendorContent
Using Drools? See what you're missing! Get the Power of Drools with the Assurance of Red Hat
A Guide to Branching and Merging Patterns
Why NoSQL? A primer on Managing the Transition from RDBMS to NoSQL
Lost comments
by
Thomas Mueller
Posted
Re: Lost comments
by
James Vastbinder
Posted
Re: Lost comments
by
Stefan Wenig
Posted
Re: Lost comments
by
Thomas Mueller
Posted
Re: Lost comments
by
Stefan Wenig
Posted
Re: Lost comments
by
Thomas Mueller
Posted
Re: Lost comments
by
Stefan Wenig
Posted
Hibernate and other ORMs vs. LINQ
by
Duraid Duraid
Posted
Re: Hibernate and other ORMs vs. LINQ
by
AVINASH HOTA
Posted
Re: Hibernate and other ORMs vs. LINQ
by
Stefan Wenig
Posted
-
It seems the comments of this article are lost.
-
Yes - I'm looking into what happened. It is my hope that we can recover the comments as we place a very high value upon them.
-james -
Too bad. Thomas, if you're still listening, i'd still like to learn how you think you can use syntax like this:
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. -
The trick is to use Object identity. Let's say you have:
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 -
Clever. So that's why your test domain classes use Integer and Double member variables instead of int and double - because they need identity for every single value, right? But this is hardly the case for real-world classes, is it?
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. -
In regard to the comparison between Hibernate and Linq, I believe that Jimmry neglected a major difference that differentiates Linq from all the other ORM frameworks which is Linq is a compile time query language while others are done at runtime. This is a major difference because that generated and verified with the compilation and that's not true for other tools that use xml files to map to the database.
-
> use Integer and Double member variables instead of int and double
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. -
Wow, you are pretty fearless when it comes to creating weird dirty tricks to overcome language limitations. I agree that you've found a clever way of integrating query syntax into compilable Java, but that's tough stuff:
- 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. -
Its great to know that , Linq is compile time query language, but it is important to know that , wht level of flexibility Linq provides as compare to Hibernate in the areas of Composite keys handling, etc.
-
I'll try again: LINQ is just a language feature, and a concept. LINQ alone has no idea of databases, XML stores or any other data storage and retrieval technology, only a concrete LINQ provider will do this (and support composite keys or not etc). LINQ cannot be compared to Hibernate. .NET developers will probably use LINQ for NHibernate (a provider) soon. However, you can compare Hibernate (or NHibernate with LINQ support) to LINQ 2 SQL, or MS's forthcoming Entity Framework.
10 comments
Watch Thread Reply