 MyGeneration wrote: |
Frans, the LLBLGen architecture it is slower than dOOdads in a simple
fetch, it has to be by it's very nature, we do not create objects to
represent each row in the database.
|
|
See, this is telling not the whole story. Of course, creating objects
is slower than creating a simple datatable with a lot of rows. But
LLBLGen Pro can do that too, even in a typed datatable: create a typed
list from just 1 entity and you're done. Or create a dynamic list in
code, using the entity meta data and construct the filter on the fly
using type safe query elements which result in generated SQL.
I don't mind if people say that their solution is fast, I do mind if
people start telling stories that what LLBLGen Pro does is 'slower'
based on a dull test which fetches 300,000 rows into a datatable. ANY
O/R mapper would be slower in that scenario, however who fetches
300,000 rows into a datatable?
I never claimed dOOdads was more powerful nor did I even make the
initial claim that it was faster, but I think fetching data via
dOOdads, based on Patricks test, seems to indicate that it is
faster. dOOdads is simple in it's very nature, it was meant to be,
however, that doesn't mean it cannot be used on complex projects,
indeed we use it, and our customers use it.
|
|
Context, that's what's important. If I have to fetch 10 customers with
a filter and for each customer their latest 10 orders and for each
order the order lines, LLBLGen Pro can do that very efficiently, by
using prefetch paths fetching a graph using graph nodes (1 query per
graph node). Can you do that too? I don't think so, as it requires
dynamically generated SQL. The problem thus is: in what context is one
slower than the other? That's important here.
I don't mind if some code generator generates code which fetches data
into a single datatable faster than my code which fetches data in a
single entity collection, I do mind if that's then used to simply say:
"We're faster, you're slower". As that's definitely not the case in a
lot of situations, and you know that too.
We are working on MyGeneration 2.0, which is being rewritten from the
ground up in .NET 2.0. We are using the "Actipro Software" suite
of tools, including their Syntax Editor. I am also working on dOOdads
II or EntitySpaces which is based on C# 2.0 and the new ADO.NET Managed
Provider information. We are adding NexusDB and Pervasive SQL support.
EntitySpaces will be supported for at least 13 database systems. It's
quite an undertaking for weekend/evening warriers but we will get it
done. Both MyGeneration 2.0 and EntitySpaces are underway
.... |
|
We used SyntaxEditor for our template studio IDE as well, it's pretty
solid. 13 databases is a lot, the time spend to support all the
meta-data retrieval routines for these databases is not spend on more
depth in the feature set, something we found out is more important than
a gazillion databases on the support list (though our provider oriented
model (it's nothing new, everyone can do it already in .NET 1.x) allows
me to add a database tomorrow if I like).
..NET 2.0 will indeed be a good point to see who did his homework and will stick around and who didn't.
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website:
http://www.llblgen.comMy .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)