# Tuesday, July 19, 2005
« It just occurred to me...why extremes ar... | Main | See the LLBLGen comments from July 18th.... »
When code generation goes bad....

I have tons I need to blog about but no time to do it, as once again I am up to my head in projects. So this entry is going to be to vent....

One of my current clients is requiring me to use a product called LLBLGen Pro (see it at http://www.llblgen.com). I am certain it's a powerful product, and while it generates enough code to make a COBOL program to look efficient, it seems to perform OK, although my gut tells me this thing would be a pig in a high-demand environment. But here's my gripe -- the documentation is horrendous. I have spent at least 50 hours trying to get this thing to generate code effectively as well as consistantly. And even then, I don't understand a tenth of what's generated. I understand enough to make minor changes, and after a lot of wrestling, I can finally get it to generate code. OK, 50 hours may not seem like a lot to learn a new paradigm which might reap a lot of benefits later, but let me tell you what that 50 hours (billable to my client, I might add, since I begged them after 10 hours to scrap it) bought you. I managed to add 2 fields to a table, and add two tables. The two new table still don't work right.

Let's put that into perspective. First, I code lightning fast. Not spaghetti code mind you, but robust code which typically is right the first time. In that 50 hours, I could have re-written a good chunk of the app, and believe me, it needs it. Fortunately, I did my consultant's duty to bring that point up. It would have taken me three hours tops to make the changes which we are looking at 50 hours and still not working. 

Second, the code is difficult to read at best. The project has fallen behind because of the insistance we use this tool, so they brought on two other developers. Guess what, they are having the same problems. They have spent two solid days now, and not one line of code written. Using standard objects, any developer with experience in .Net can peruse the object model quickly and begin coding. Not with this tool!

You can't compare CodeSmith, which I have praised before, with LLBLGen. LLBLGen is far more sophisticated, unfortunately to the point of being unusable. I know there are a few people who swear by it, and that's great, but I get paid to come in and make a difference fast, and LLBLGen has proven to be more an expensive hindrance than a solution.

OK, that's the end of the vent. I have been deploying some web services for another client, and once we have everything debugged, I have a ton of tips related to web services and deployment which I promise will save a ton of hours to other developers entering into this domain. Until then!

 

All Things | ASP.Net | Design | General | Tools
Tuesday, July 19, 2005 5:49:51 AM (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |  Comments [5]  |  Related posts:
Tip of the Day: Testing emails by saving them to files
WinForm Tip: Dynamically change the font color of a ComboBox or ListBox
Tip of the Day: Convert XmlDocument to XDocument
More adventures in hosting - Why I would NEVER recommend ASPNix
Tip of the Day: Creating a control that displays multiple types of messages using the IValidator interface
Tip of the Day: The evolution of dynamic, case insensitive LINQ to Object search
Wednesday, July 20, 2005 8:54:15 PM (GMT Daylight Time, UTC+01:00)
If you had such a hard time, why didn't you just mail us with your questions?

Secondly, if you want a product with a lot of features, the learning path is a bit steep. The documentation contains 289 pages and is often praised as very good and complete, so 'horrendous' is IMHO a classification not doing it justice. Every documentation is incomplete as there's always something left to be documented. Though our documentation covers more bases than most competing products will.

"I know there are a few people who swear by it, and that's great, but I get paid to come in and make a difference fast, and LLBLGen has proven to be more an expensive hindrance than a solution."
heh, a few... well, you can honestly say, a lot, not a few. But that doesn't help you of course, so I'd like to invite you to mail us your problems with LLBLGen Pro and we'll try to get you up and running a.s.a.p. Also our active community forums can help you further perhaps in the first steps.

I must say that you're one of the first who classifies our product the way you do, as if there's nothing it can do right.

So, let us help you, or the active community help you. The functionality is there, and it perhaps takes a few basic things to get you up and running.

Oh btw:
"and while it generates enough code to make a COBOL program to look efficient, it seems to perform OK, although my gut tells me this thing would be a pig in a high-demand environment"
Compact code isn't necessarily efficient. The code is written with speed in mind and is in use by a lot of large companies in enterprise applications. It sports a lot of features and thus there is more code than your basic class with 10 properties.
Frans Bouma
Wednesday, July 20, 2005 9:23:17 PM (GMT Daylight Time, UTC+01:00)
Franz,

Thanks for making the comment. I am glad you took the time, as obviously it's fair both sides of the equations are represented, and I welcome the chance to present both sides for the 5 people who might stumble on my blog.

As far as coming over to the community and asking questions, I have, and that experience was very positive. The response was quick, professional and very effective in solving the issues I was encountering.

But in disagreement with your comment "there's nothing the product can do right", that's just not true. It generates code. (A lot of it. If I had the time I'd love to put it through some tests to see how well that code performs. Like I said, it's a gut feeling I have, nothing more.) But I will say once I get it working, it *does* work. It's the getting from point A to B that caused a LOT of frustration, and my comment was certainly written during a period of that frustration, so readers can take that in mind when reading it if it wasn't that obvious.

Whether the lot of code is a good or bad thing from a developer side I guess is a matter of developer taste. I will say this --> when a new developer (or contractor as is my case) comes in to work on the code, expect a learning curve due to the complexity of the model. And many would consider that an issue, especially when you are paying a lot of money per hour for that help. I think in that scenario, a company would be well recommended to finding someone with some considerable LLBLGen experience unless it's a longer term project and the company is willing to invest the time necessary. From my experience and my client base however, it is immensely important another developer can come in and begin coding to the object model immediately. So in this case, you'd want someone with LLBLGen experience.

As far as my comments on the documentation, I think a tutorial at the beginning (if it's there, I guess I missed it, which is possible because I was given a very short deadline and I needed to generate the code fast) which goes through the concepts in depth would be very helpful. Once again, if it's there, then I apologize. I will say the documentation there is plentiful and professionally written, if not a bit hard to understand at times. So once again I think the horrendous comment was once again a reflection of my frustration at the time (the dangers of blogging angry perhaps?).

I think another thing which caused some frustration on my part is how errors are handled. While I think it's great that the full error is handled properly, sometimes the error message is cryptic at best. Essentially, it's the .Net error, and to a newbie like myself, trying to interpret what it's telling me is difficult. If there was a more user-friendly message or suggestion I think it would be immensely helpful.

I am very supportive of Code Generation, and anytime it's adopted the benefits are immense.
Daryl
Thursday, July 21, 2005 2:30:22 PM (GMT Daylight Time, UTC+01:00)
LLBLGen should not be thought of as a CodeGen tool like CodeSmith. LLBLGen is an ORM framework that is meant to generate your DAL (Data Access layer) for your database. The DAL code it generates can be (and properly should be) used as DLLs that referenced by your BL (Business Layer) project. Your UI (User Interface) project should reference your BL project.
This way you have a true logical n-tier architecture and you gain the following bonuces:
1- LLBL’s DAL code should NOT be edited. It is there to serve your BL. If you modifu your database, then all what you need to do is re-generate your DAL (process takes 4 minutes for a 300+ table database)
2- LLBL’s DAL can be generated to target several database platforms without you having to change a single line of code in your BL (example, migrate database from ORACLE to SQL and just re-generate the DAL for the new database. You are done!!)
3- LLBL uses a data-base drive approach that allows any willing LLBL user to write a driver for a DB not supported by LLBL
4- LLBL does NOT force any methodology for consuming its DAL code in both the BL and the UI tiers. This allowed a lot of different implementations by LLBL’s users. The 3rd party link provides templates for the Manager design patter and the JCL framework (CSLA.NET implementation using LLBL).
5- LLBL offers two template languages that allow for any level of complexity in writing your own templates for your BL and UI
6- LLBL offers (include templates) and (code regions) that allow you to inject your own code into LLBL’s templates without modifying those templates
7- LLBL’s templates support generating C# and VB.NET
And (this is my favourite..)
8- LLBL does NOT utilize Stored-Procedures for CRUD operations on tables and views (it does support calling Stored-Procedures by wrapping them in functions). After trying to write an ERP with 300+ tables using CSLA.NET, only converting to LLBL saved the project (try to maintain a minimum of 5 SPs per table!!)

In addition, LLBL is perfectly suited to team-development because how it segregates the different tiers of the solution. (Architect takes care of modifying DB and generating DAL, while the developers are either working with the BL or the UI)
Omar
Thursday, July 21, 2005 4:22:41 PM (GMT Daylight Time, UTC+01:00)
Daryl,

Please call me with any questions you may have man. You can get my number from Shaun or Stephen. I'll be glad to help you out.

I know the app isn't all pretty. Welcome to the unrealistic deadlines of said client.

Chris
Chris Martin
Thursday, July 21, 2005 4:43:58 PM (GMT Daylight Time, UTC+01:00)
Chris,

Thanks for the help you did give me. Between your help and the help on the forum, I was able to finally get over the hump I was on at the time. The vent was a result of knowing that what I needed to do was small, but it was taking so long (under a lot of pressure) to get it done. But thanks again for the help...

Daryl
Daryl
Comments are closed.