Jay2007 wrote:
I have used LLBLGEN on a previous assignment and found the product to be very stable and very productive. Performance was also quite acceptable. But, my only grouch is that the syntax is patently complicated - albeit elegant. In my current project, we are using SubSonic (formerly called ActionPack and based on Ruby on Rails) and when I compare the two, I find that the syntax in SubSonic is far more intuitive and does not expose patterns-related and architectural verbiage to the user of the framework. I am not saying that SubSonic has everything that LLBLGEN has but from what I have used of it, it gets CRUD done and exposes SPs - output parameters and all. Though, validation support is not flash and it seems to have no COM+ support and provision for more complex query constructs are just not there. But then, even with LLBLGEN, I tended to go the SP way for complex queries.
I bring this up because, I had the unenviable task of training my juniors on how to go about using LLBLGEN - I was not exactly a seasoned LLBLGEN developer myself. When I first mentioned PredicateExpressions to them, they blank-stared me and thought I were AL himself. But when I told them it was merely a "WHERE" clause, their eyes lit up - and with it, my intelligence quotient in their eyes took a nosedive.
A WHERE clause is a predicate expression, a single clause in a WHERE clause, e.g. CustomerName == "SomeName", is a Predicate.
LLBLGen Pro uses type safe predicates, and not string based predicates. This is a design choice to be able to check at compile time what's wrong instead of at runtime. You can't compare it with Ruby related stuff as Ruby doesn't compile up front.
In essence, wouldn't it be better if we used simple, non-architectural terminology so that the newbies are able to map their SQL knowledge to LLBLGEN with little difficulty.
When I had to guide my juniors on SubSonic, they got it instantly. After all, the idea of using an OR/M tool like LLBLGEN is to eliminate the drudgery of DB coding without a steep learning curve.
The problem is that unless a standard terminology is used, you can't use any other terminology to name things and refer to things, as everybody names the elements differently. So I used the standard terminology with databases. Not all of it, though. I don't use the mathematical background on predicates, I don't use the word 'tuple' in any way, though at some point it you have to refer to elements and it's then best to use the term which is the standard term for it.
That said, creating predicates is quite easy these days with the operator overloading. It's still not LINQ, but it's better than the class oriented approach we had earlier. There are however very little alternatives, as a string based query approach is out of the question.
You have a great product here and this is not meant to be a criticism. Merely a suggestion to make this really cool product more accessible even to people with minimal coding experience.
bye,
Jay Shanker
PS:
Pls. dont flame me over this. This is just a constructive observation not meant to criticise or belittle the product. I am a happy user of LLBLGEN and will recommend it for its great performance and productivity.
Any critizism, with arguments, is welcome. I understand your point, though I don't see how define things differently without writing a second manual just for the novice developer. You see: LLBLGen Pro is a tool for software developers. if the software developer has little experience with writing software, the problems related to converting an algorithm to code are also causing problems with understanding how LLBLGen pro works.
We did try to explain filtering etc. much better in the v2.0 manual, as it was indeed a bit cryptical documented.
) the crudest way to explain it is 1:1 extended relations on tables, at least for me anyway.As Fran's stated in his post. The biggest obstical is knowledge/experience base of the programmer.