You know every day i have to try and convince people that using a object that generates the required SQL is beter for development time and maintaining of code than using the normal native .net SQLClient controls where you have to type SQL as strings!

Why?

The normal SQLClient objects DataAdapter, dataset, connection and command is very cumbersome to work with - and time consuming especially if you only want to find a quick value.

LLBLGen makes this all so easy - Maybe thats the problem with those people, if something is not complex then it can't be good.

I know there has been alot of discussions about the speed between SProc's and LLBLGen.

But you know what - Even if LLBLGen was 1 second(Very extreme) slower per transaction than doing it the normal .Net way i would still use LLBLGen just because development time is so much faster and the maintaning of code is so much simpler.

LLBLGen actually forces you to develop you database properly - And that can only be good thing.

If you want to take forever to create an application that is suppose to be fast - be my guest and type your SQL the olf fashion way.

I Love LLBLGen

Tell me about it. My blog entry about stored procs: http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx already has 131 reactions and counting. Every week someone comes in to tell me I suck or don't get it

It took some time till I got convinced btw. I lost 2 months of development time (feb-apr 2003) of LLBLGen Pro because the initial design was completely wrong. I had it designed like this: first you design the stored procs (with a visual editor, I was halfway through this, complete visual expression designed ), then you group the procs in classes, then you group the classes in BL components.

However this would take aaaaaages to complete a development cycle. Even with smart wizards I had (create all crud procs for selected tables etc.), it still would take ages to create the different queries with custom filters.

This was a hard lesson, however I'm glad I did made up my mind, changed the way it worked and started over for the core design.

There is still a good flamewar somewhere in the asp.net forums between me and Thomas Tomiczec where I try to convince him dynamic sql is crap and stored procedures are the way to go (He's now a good friend of mine, btw, but that thread is a great read I'll try to find it back)

I understand that existing systems have stored procs for inserts, updates and deletes, so you can't expect people to go and redo their work. Expecially where i am working now - thousands of Sprocs .

I am a firm beleiver that you use the technology that will be the easiest to maintain in the long run for a specific job NOT the technology that will give the best results neccesarily. Maybe i am wrong, but as a developer i will be the one doing the work in the end. For example Assembler and C++ is faster executing code than .Net CRL - **Why don't we all use it? **Because it is harder to maintain and takes longer to do the job. Now why should communication to a database be any different?

Okay - Network traffic will be more in a complex piece of LLBLGen logic if your DB and Web Server is two physically different machines - so ask yourself is LLBLGen the best tool for this specific section of the job?

When i stated

Why is it that people still want to use inline SQL and SProcs?

I was talking about cowboys that want to hard code SQL Statements in their command objects and write Sproc for every simple DB I/O operation (This does seem to be what microsoft invisioned if you look at the .NET CommandBuilder).

I use to be a Delphi developer (Ex Best tool for windows! ) and had to code the DAL out by hand. Why? ahhhhhhhhhhhhhhhhhhhh!!! Where was LLBLGen then?

I discovered LLBLGen when i started doing a job for Circdata in April 2004(Only a month ago). I have my own company that was started in Oct 2002 - i did not know about LLBLGen so i started my own Framework of classes that wraps the .Net SQL Classes, i also wrote a generator that looks at a DB and constructs entities and collections specific to that DB. That piece of technology was develop just to speed up my own development of software it is shockingly simular to LLBLGen with a few exceptions. I still use my own framework for my company but use LLBLGen for circdata.

Some insight into my framework. In my framework i have a basestoredproc class that handles the generic calling of sprocs & functions. I implemented this class into my baseDataProvider class as a property so all Entities and collections could call sprocs in the same connection and transaction if they had to. This is there because you do need to call SQL functions and procs sometimes.

I am not trying to sell my framework as it is not for sale (It gives me the edge over my competion for NOW).

The nice thing about using these type of classes is that you as application developer do not need to know the complexities of the database that you are working with - so that brings in a layer of security it self.

You could almost give a developer the classes and tell him to go and develop the application at home without the Database or any knowledge of the Database (Maybe i am expecting to much from my developers ).

The pros of using classes that generates dynamic SQL outweighs the disadvantages.

I think i might join the discussion at http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx