Hi, you say that LLBLGen Pro saves time.

When looking at simple examples like

CustomerEntity customer = new CustomerEntity("CHOPS");
orderGrid.DataSource = customer.Orders;

there's no way than to agree...

However, I am looking at the rest of the story - about 300 pages of documentation to read, a new object model to learn and time needed to work out so much experience to be able to manage the more complex scenarios as easy as the simple ones.

I think, many people have given up using O/R mappers when they realized these challenges - even more, because time is always a critical ressource in real world projects.

What do think about the time spent to learn the product compared to the advantages one gains? What do you think about how long should one experiment with LLBLGen, before using it in a real world project (considering a developer who knows C# but never worked with such a product)? Which learning curve should we include in our project planning?

Thanks for your comments, Mario

I think I know where you're coming from and I've only recently started using LLBLGen.

Personally I would say its been pretty simple to pick up. The manual draws attention to the main features quite clearly and the support on this forum is exceptional.

Most of the time its just 'get this object' or 'get this collection with this filter and sorting'.

Ian.

I think I know where you're coming from

Does that matter? If yes, please stop being anonymous...

Anyway: thanks a lot for your comments.

I would highly appreciate statements of other users who have just started to work with LLBLGen Pro. What was your experience considering the learning curve?

Best Regards, Mario

There's always a learning curve of course. THe more features there are, the more things you have to learn. If a framework can do just one thing, it's easy to grasp, but as soon as you want to do more, you need more features and thus more things to learn, that's unavoidable.

You don't have to learn everything up front though. The main things to grasp are: - how to setup a filter - how to use the advanced features like expressions on columns, aggregates and prefetch paths.

For example, in the documentation there is a 'how do I?' section. These are often asked questions which will give you some insight in common usage patterns. But they don't cover everything of course, as the scope of the complete system is massive. For example, the scope of Template studio, the template editor, is wider than Codesmith studio, and consider that template studio is an additional tool, so not even the main application

And if you have particular questions, like "I have this complex query and I don't know how to write the predicates for it" or other questions, just ask them here, in no time you'll have the answer. Regularly, new users ask 2 to 10 questions and after that they're skilled enough to get things working, and occasionally ask an advanced question like 'what's better: this or that?' .

Rely on the code samples in the docs. I once printed out the entire manual and read most of it. But I find that mostly I rely on the sample snippets of code.

This support forum is top notch and you can always get quick answers here.

Lets suppose you have a 1 to many relationship and you wanted to update 5 parent records and all of their children, e.g. you wanted to change some information on the order and order details data in northwind.

When you compare what you need to know, in order to make this happen using llblgen vs. ADO.NET, there is much more that you need to know to make this happen in ADO.NET.

The llblgen objects encapsulate this operation for you, so, when compared with what you need to learn to write the procs yourself, hook up the procs to ado.net (or some other mechanism), and then get the data from the UI and back again, you should find that you get done alot faster using llblgen pro.

You mention saving money in development time and "the learning curve". Thats just one peice of the software development lifecycle. IMO, using a good layered approach makes your code more solid and maintainable and easier to deploy, so, you can save money getting the code out the door if you already know ado.net, but will it be as flexible, database independent, and maintainable?

FYI, if you want to work in an industry where you wont need to learn new tricks to stay competitive in the marketplace, you might want to consider a career change!

I am a new user, and I think the comment is right that 2-10 questions is common. I am up to 3. In my opinion, LLBLGen saves a lot of time during database development. Add or rename a column and simply regenerate the DAL. That coupled with the strongly-typed objects and intellisense outweights the inconvenience of learning what is essentially a new query language.

It would be very helpful for new users if the LLBLGen web site had a query solution browser that hosted SQL queries and their equivalent implementations using each object model. I envision something where users can post their queries and solutions in some kind of browsable format.

LLBLGen is very capable. Most often, the question is "how", not "if", but finding that how can be difficult even with the documentation

benles wrote:

It would be very helpful for new users if the LLBLGen web site had a query solution browser that hosted SQL queries and their equivalent implementations using each object model. I envision something where users can post their queries and solutions in some kind of browsable format.

With the new search engine on the forum, installed last weekend, we now have the option to add pre-fabricated search queries on the website, which will bring visitors directly a list of answers they are looking for.

Your idea is a good one though. I've tried to add some basic examples of the predicates to the HowDoI section in the docs, but it's still pretty limited. One reason for that is that there are so many complex queries possible, it's hard to describe them all.

Often, when the user is new, they think in sql query terms, while they should think in 'I have a complete set of all objects, and I want a subset from that complete set, lets define the filter for that complete set, so in other words lets define the filter which defines that subset'. It's not hard though to make that step, but it's a step to be made, and the more help they can get, the better. I'll give your idea some thought, thanks for the input!

Leveraging the code snippet tool in vs.net 2005 might be a good helper too (when we get there)

Devildog74 wrote:

Leveraging the code snippet tool in vs.net 2005 might be a good helper too (when we get there)

Of course .

mario.muja wrote:

I would highly appreciate statements of other users who have just started to work with LLBLGen Pro. What was your experience considering the learning curve?

Sure there is a learning curve, but it wasn't that bad. For us, the two biggest advantages of an O/R Mapper is that it has basically taken 1/3 of our architecture out (the DAL piece) and it provides robust business objects that can be passed from layer to layer. Before, you had to labor over every little piece of functionality and stored proc and the methods and properties your objects will support. Now, it matches your DB and it supports everything!

Specifically regarding LLBLGen Pro: I love the omnipresence of Frans/Otis and his ability to provide input in almost every thread and yet introduce major enhancements to his product plus completely new tools on a regular basis. I sometimes wonder when the guy has a chance to sleep.

Once I "got it", I had no problems shelling out the purchase price from my own pocket for a side gig and haven't looked back since.

mattsmith321 wrote:

Specifically regarding LLBLGen Pro: I love the omnipresence of Frans/Otis and his ability to provide input in almost every thread and yet introduce major enhancements to his product plus completely new tools on a regular basis. I sometimes wonder when the guy has a chance to sleep.

I wonder that myself sometimes as well . It's mostly tight planning, and a tough schedule what to do every day.