Hello,

I am new to O/R mapping and have a question, several actually.

When looking at retrieving filtered collections of objects using LLBLGEN, I see that you must use predicate expressions, predicate relations (to represent joins), and the predicate relation bucket.

In essense, you are writing the query (joins + filter) using an object based approach. This format is incredibly verbose compared to the SQL equivalent of an expression, ie. a simple expression like "(field1 > field2 or field3 < (0.5 * field4))" is very verbose using predicate expressions compared to the equivalent SQL expression shown.

My question is for someone who has used LLBLGEN. I see huge time savings by using the O/R mapper approach for simple table and relations operations, but when you take into account the verbosity (if that is a word) of the expression language compared to traditional SQL expressions, does it still end up being beneficial to use the O/R mapper?

I am just struggling in trying to weigh the increase in complexity of the expressions versus the beautiful lack of having to generate stored procedures for everything?

Is there an SQL type expression object where you don't have to use those verbose predicate objects for every filter, but instead can insert simple SQL WHERE clause expressions with parameters?

Lastly, why do we need to add relation objects to the predicate relation bucket when the relations in the project have already been defined?

Thanks very much for your time.

I am really hoping someone with more experience than I can shed some light on these issues for me and set me on the right path.

Thanks.

S Shannon

The new version that is currently in beta makes the predicate building much easier and more readable. As long as you are using C#.

I think if you search around for 1.0.2005 you will find the thread on it.

BOb

I'll give you my 2 cents.

can1 wrote:

My question is for someone who has used LLBLGEN. I see huge time savings by using the O/R mapper approach for simple table and relations operations, but when you take into account the verbosity (if that is a word) of the expression language compared to traditional SQL expressions, does it still end up being beneficial to use the O/R mapper?

Well first of all, there is an update on the road that will allow you to write queries using operator overload, which will significantly reduce, er, verbosity (I'm not sure if it's a word either)

Even without that improvement, I still find it beneficial. The O/R mapper is still a huge time saver. I like these facts:

• The O/R mapper gives you a more strongly typed version of your data model. So you get a lot more errors at compile time than if you used plain SQL which is essentially unchecked until runtime. This becomes essential upon database design changes!
• The O/R mapper gives you easily usable DTOs to transfer data between your system layers. These DTOs reflect your data structures as they are generated from your tables. So you won't have to manually code a DTO again, that's a time saver. And you can databind entities
• Using the designer you can have a more expressive data model than your data base, for example using entity inheritance or some of the neat features in the project designer such as type mapping, fields mapped on entity fields, etc.
• Many more reasons... possibility of independence from a concrete database, assurance of join correctness, but these are the ones that make up for most of the time saved in my opinion.

Remember that for more complex operations maybe a typed list or typed view is a good alternative.

can1 wrote:

Is there an SQL type expression object where you don't have to use those verbose predicate objects for every filter, but instead can insert simple SQL WHERE clause expressions with parameters?

I remember reading some other discussions about this, you should check out the forum on that subject.

Lastly, why do we need to add relation objects to the predicate relation bucket when the relations in the project have already been defined?

Adding relation objects tells the DQE to generate a join on the relation fields. Without adding the relation object the DQE wouldn't generate the join and you wouldn't be able to specifiy filters on related tables.

Of course you don't want to have every possible join specified every time, so that's why you need to tell the DQE the joins you need.

Hope that was helpful, álvaro.-

Also keep in mind that the object queries you are creating are strongly typed. This is checked at compile time. How many times has your SQL text had a typo that wasn't caught until runtime.

BOb

Thank very much for your insight. It really sounds like you must look at all the benefits gained to get a clear picture of advantages/disadvantages and it is a time saver in the end, though I am sure that I will have a bit of a learning curve on startup.

can1 wrote:

Thank very much for your insight. It really sounds like you must look at all the benefits gained to get a clear picture of advantages/disadvantages and it is a time saver in the end, though I am sure that I will have a bit of a learning curve on startup.

There is a learning curve, though it can be small if you step back from the raw SQL for a moment and start thinking in "a large set of objects, of which I want to read a subset and I therefore define a filter", which is the predicateexpression + relationcollection you've to work with.

That's one part.

The other part is the dynamic list/typedlist part, where you want to work with lists constructed from attributes of various entities, like Customer.CompanyName, Order.OrderID, Order.OrderDate. These aren't loadable in an entity object obviously, so you define a typedlist for that, or if you want to create them in code, you create a dynamic list for that (see the Typedlist documentation in the manual).