Re: Finally which ORM tool?

Frans Bouma [C# MVP] <perseus.usenetNOSPAM@xxxxxxxxx> wrote:
Oh absolutely. The difference is that if you then need to fix
something to behave in a particular way, you can do so. I suspect
there's a nice solution waiting in the wings somewhere, but I haven't
used it yet. As I say, I have hopes for WPF...

What I've seen is that they more or less adopted the asp.net way of
databinding. So nothing really helpful, but it allows you to do
'declarative programming'... yay! :/

I have no problem with the declarative side of things, and the big
advantage from my point of view is that we can do things in the XAML
directly when the designer doesn't support them, and use the designer
for the rest of the time. It's the best designer/hand-crafting amalgam
I've seen yet.

Isn't that going into the red zone of 'magic programming' ? I mean,
you have a local variable, even if it's a value typed variable, and
you have a linq query and by changing the variable's value, you
manipulate the linq query IF you're executing it at that moment.

It's probably slightly "magic" at the moment. I don't think it will
be for long. Sooner or later, devs are going to have to understand
what closures really are, and how with captured variables it really
is the variable which is captured, not its value.

'Closures', now there's a word that's overloaded too many times :).
Are we talking about sets or graph paths? :)

Um, closures the fairly standard computer science term:
http://en.wikipedia.org/wiki/Closure_(computer_science)

Don't forget that it's not just LINQ to SQL we're talking about here
- this is true for LINQ to Objects as well as anywhere else you might
use an anonymous function.

True. I saw your blogpost today with the query which looked a bit
obscure to me. Sure, it's understandable if you look closely, but
that's not the point. The point is that one easily overlooks the real
specifics of the query: a human in general has a hard time grasping any
form of computer language, simply because the human has to interpret
the code before understanding what it REALLY does.

That was deliberately nasty code. It would be fairly hard to
accidentally do that sort of thing, and I would certainly discourage
its use in real code.

And it is a declaration, but one which captures the variables. I
really don't think it's that bad, once you get used to it - it's very
similar to the whole "passing a reference type argument by value
doesn't mean all the data is copied, just the reference". Once you
accept where changes will be reflected, it's quite easy to work with
that.

Though it's a way to make things really complicated without a lot of
effort, or better: you somewhat have to PUT IN effort to make it very
clear. Perhaps not for the person who wrote the code and who has spend
weeks designing and writing it, but for the poor sods who have to read
the code after the genius left for another job.

Well, I think query expressions are clearer than text - as well as
being more easily verifiable by the compiler, of course (within the
bounds of being valid expressions - the compiler can't determine
whether or not there will be a valid SQL translation).

As for the captured variable aspect of it - I still believe it's a
matter of education and becoming used to them, as well as not abusing
them. You can certainly get yourself into trouble pretty easily, but
then again you can also *avoid* getting yourself into trouble fairly
easily.

It's an IEnumerable<T>, and therefore a resultset. If it would be a
definition alone, the queries of CHOPS would have been fetched,
simply because the declaration construction was with 'CHOPS'.

I don't see the logic in your first definition. Suppose it didn't
implement IEnumerable<T> but had an Execute() method which gave back
an IEnumerator<T> instead - in other words, we just changed a method
name and in doing so removed an interface implementation. How can
that change whether the object is itself a resultset or not? Or would
it still be a resultset in your view?

Because it implements IEnumerable, it by itself is an enumerable
resource. This IMHO implies that it's a set.

To me it impllies it's the source of a sequence.

If it had an Execute method (some o/r mappers add that method), the
thing still is that it's not a declaration alone. You can't execute a
declaration without the executor who interprets the query so it gets
executed.

Well, it's a few things:
1) It relates to a schema - crucial for keeping type safety etc
2) It knows about its current session
3) It's the query itself
4) It's the means of executing the query

I would have no objection to the idea of it not implementing
IEnumerable<T> directly but instead having an Execute method taking the
session. It would make a few bits of code a bit more long-winded, but
that's all.

Having said that, I also don't have much problem with the way it's been
done.

With Linq they placed the executor inside the declaration. Why, I have
no idea, the only guess I have is that it's 'easier' for some people
who have no clue what they're doing anyway, but then again, these
people will have a hard time with some areas of linq anyway so why
bother introducing this 'feature' for them.

The analogy is a simple SQL string: you can't execute it without a SQL
engine. To use it as a metaphore here, this is the same as linq:
string query = "SELECT * FROM Customers WHERE Country='USA'";

foreach(var customer in query)
{
// do something with customer
}

Everyone will say: "you can't execute a string". No of course you
can't, as it contains the declaration of a query. You need an execution
engine to execute the query. That would have been better IMHO, because
it separates declaration from execution, which are combined in a linq
query.

Well, you need *context* - and that's what the DataContext (and the
tables off it) really provides.

I really don't think it's nearly as ugly as you seem to be making it
out to be though.

The query itself doesn't contain the data, it simply contains all the
information required to fetch the data. That doesn't make it a
resultset in my view. It's all a matter of definition though.

Something which is enumerable, isn't that semantically a sequence, a
set for you?

Sequence and set certainly aren't the same thing, but I'd say that
something which is enumerable is either a sequence in itself or is a
way of getting at a sequence. Think of it in terms of the method:
GetEnumerator returns an enumerator for the data. There's nothing
inconsistent in that being applied to a data source rather than
something which already contains the data.

Because the linq query isn't a declaration alone, you can't do things
with it like pass it to an execution engine of choice, you have to
execute it with the engine inside the query, or you have to be lucky to
be using a linq provider which gives you this flexibility ;).

Sure - but the beautiful thing about LINQ (instead of LINQ to SQL) is
that different providers can choose their own way to go on this and
people can still use broadly the same query syntax. If you choose to
implement LINQ in a way which requires a context to be provided to it,
that's fine - and the query will still be easily recognisable to
someone who has used LINQ to NHibernate, or LINQ to SQL.

The fact that the execution doesn't happen at the declaration means
it's deferred execution by every other use of the phrase that I've
ever seen.

You're using "deferred execution" to mean what I'd probably describe
as "deferred parameter evaluation". It's an interesting topic to talk
about, but I'd prefer it if we didn't keep calling it "deferred
execution".

Sure, I don't like word-games, so I don't mind.

It's not a word game - it's a matter of accepting the common
understanding of a term. If you use the phrase "deferred execution" to
mean "deferred parameter evaluation" you *will* confuse people.

The thing is though
that I find it very important that people understand that the place
where the executor is located in a linq query is an important issue,
and not something you can simply wave away as 'not that important'. The
thing is that it severily limits the user of the framework in how s/he
wants to use the query, while it doesn't give the user any real
benefits, except perhaps the 1 line of code they don't have to type now.

How does it "severely limit" the user of the framework? If you don't
want to change the parameters, don't change the values of the variables
- I don't think it's something that people are likely to do
accidentally anyway, to be honest.

Now, you also bring up another topic: separating the query from its
data connection. You can't easily separate it from its whole data
context in terms of the types involved, because at that point you
lose a lot of the benefits of LINQ - but I could certainly envisage
separating it from a "live" context. I don't know what LINQ to
Entities will have, but I wouldn't be at all surprised to see that in
there.

Depends on if they still move ahead towards a multi-db design. I have
the feeling they won't, as it could give their competitors in the DB
market the same advantage SqlServer will have now (as IBM and Oracle
have already made their DB engines capable of running these kind of
engines in-process so it won't be hard for them to move an EDM layer
into their databases, IMHO).

I will be very disappointed if they don't go for a multi-db design.
It's not going to stop other projects from going multi-db (such as LINQ
to NHibernate) - it would just limit the usefulness of ADO.NET
Entities. Put it this way: people aren't likely to change their
database choice based on what ADO.NET 3 supports, but they may well
change their framework based on their choice of database. MS would be
foolish not to understand that.

--
Jon Skeet - <skeet@xxxxxxxxx>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
.

Relevant Pages

  • Re: Finally which ORM tool?
    ... you manipulate the linq query IF you're ... implement IEnumerablebut had an Execute() method which gave ... Every Linq provider will implement ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Finally which ORM tool?
    ... of a query;), hence my question. ... IEnumerabledirectly but instead having an Execute method taking ... But it's not a problem with LINQ itself. ... Every Linq provider will implement ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Finally which ORM tool?
    ... Also, if you pass a variable to the query, the value the ... you have a linq query and by changing the variable's value, ... q is affected if I change foo AFTER this query and BEFORE execution. ... And it is a declaration, but one which captures the variables. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Is LINQ consumes double the time of Traditional Data Connection?
    ... What about the next time you execute the query? ... This makes sense - not only has LINQ got to connect to the ... That assembly can be reused for subsequent queries, ... Try measuring the subsequent executions of the same query and I'm sure ...
    (microsoft.public.dotnet.general)
  • Re: Finally which ORM tool?
    ... method used INSIDE the query is passed as the value immediately, ... That's also info not NEEDED to write correct queries on the ... Sequence and set aren't equal, true, but in this case, where linq ... to use the subquery train, I have to use joins, or rely on the provider ...
    (microsoft.public.dotnet.languages.csharp)