LLBLGen compared to DataSets

Posts   
 
    
mario.muja avatar
mario.muja
User
Posts: 37
Joined: 03-May-2005
# Posted on: 26-May-2005 00:58:51   

Hi, I am interested to get more information about what I can do with LLBLGen that is not possible with DataSets/DataTables or one of the wizards in Visual Studio.

I would highly appreciate not only the LLBLGen team but also current users of the product to name features that are most important for you when comparing with DataSets.

A simple example: LLBLGen generates SQL statements for me. Fine. However, there's a wizard for SqlDataAdapter in Visual Studio. This wizard also creates SQL statements for me. What's the real benefit here? I would say, the functionality of the DQE by means of dynamically generating SQL that best fits the current context or task, right?

Do you know other examples, where a similar feature exists in VS.NET / DataSets that may seem equivalent to a novice developer when comparing with a product like LLBLGen?

Best Regards, Mario

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39933
Joined: 17-Aug-2003
# Posted on: 26-May-2005 11:53:10   

mario.muja wrote:

Hi, I am interested to get more information about what I can do with LLBLGen that is not possible with DataSets/DataTables or one of the wizards in Visual Studio.

I would highly appreciate not only the LLBLGen team but also current users of the product to name features that are most important for you when comparing with DataSets.

A simple example: LLBLGen generates SQL statements for me. Fine. However, there's a wizard for SqlDataAdapter in Visual Studio. This wizard also creates SQL statements for me. What's the real benefit here? I would say, the functionality of the DQE by means of dynamically generating SQL that best fits the current context or task, right?

Do you know other examples, where a similar feature exists in VS.NET / DataSets that may seem equivalent to a novice developer when comparing with a product like LLBLGen?

Well, picture yourself a database of 100 tables with on average 5 fields per table, of which one is a PK. that's 4 fields per table. I think you can imagine how many different update methods you can create to update these 400 table fields, in whatever order. Also the amount of different filters on the tables will grow out of proportion if you have to write them by hand up front in procedures for example.

I.o.w.: if you don't have a dynamic query engine, you're up for a lot of work. Let's say I bind a graph of customers -> orders -> orderdetails to 2 grids (master-detail) with customers in the master, and orders in the detail. THen I alter all kinds of data in the order details, add a new order, new customer with orders etc. etc.. I then simply save recursively the customers collection and all queries are produced for me, automatically. PK's are retrieved from the db if they're identity valued, PK's are synced with FK's, all queries are executed in the right order.

One line of code.

If you can beat that with a dataset, go ahead simple_smile

Frans Bouma | Lead developer LLBLGen Pro