To SPROC or not to SPROC

Posts   
 
    
esmith
User
Posts: 3
Joined: 27-Sep-2005
# Posted on: 27-Sep-2005 16:28:58   

I'm sure this is a common feature to do, and I want to make sure my development team is using LLBLGen in the way in which it was intended to be used.

We have a search screen with 8 free form text inputs, each of which the user can say they want an exact match, we also have a couple of bit fields and an int field the user can select to build a query that returns a subset of data from FOUR related tables from a "typed list".

I would like to know the best way to approach this with "bgen" to keep the coding effort small while using your product in the most efficient way. I find that a lot of time the developers would rather write a stored procedure than coding the relations, the predicate filters etc...

Following is the code for JUST ONE of the 8 free form text fields. As you can see the code will get quite long the way we are doing this now. Some 300 lines of code. If we were take take the parameters and feed them to a SPROC, the SPROC is about 10 lines of code to return the results.

We just want to make sure we are using "bgen" the best way.

//Rep First Name filter: (tbus_first_name like '%' + RepFirstName + '%')
if( RepFirstName.Trim().Length > 0 )
{
    RepFirstNamePredicate_Like = PredicateFactory.Like(TbUserFieldIndex.TbusFirstName, "%" + RepFirstName + "%" );
    RepFirstNamePredicate_Equal = PredicateFactory.CompareValue( TbUserFieldIndex.TbusFirstName, ComparisonOperator.Equal, RepFirstName );
}

//RepFirstName
if( (RepFirstNameExact == false) && (RepFirstNamePredicate_Like != null) && (OnePredicateAdded == false) )
{
    Filter.Add( RepFirstNamePredicate_Like );
    OnePredicateAdded = true;
}
else if( (RepFirstNameExact == false) && (RepFirstNamePredicate_Like != null) && (OnePredicateAdded == true) )
{
    Filter.AddWithAnd( RepFirstNamePredicate_Like );
}

if( (RepFirstNameExact == true) && (RepFirstNamePredicate_Equal != null) && (OnePredicateAdded == false) )
{
    Filter.Add( RepFirstNamePredicate_Equal );
    OnePredicateAdded = true;
}
else if( (RepFirstNameExact == true) && (RepFirstNamePredicate_Equal != null) && (OnePredicateAdded == true) )
{
    Filter.AddWithAnd( RepFirstNamePredicate_Equal );
}

ATMList = new AtmadminListTypedList();
ATMList.Fill( 0, null, true, Filter );


Thanks!

Eric Smith

ianbanks
User
Posts: 9
Joined: 21-Sep-2005
# Posted on: 27-Sep-2005 19:07:24   

esmith wrote:

I'm sure this is a common feature to do, and I want to make sure my development team is using LLBLGen in the way in which it was intended to be used.

...

Eric,

I've only been using LLBLGen a short period of time, but I've come to prefer the predicate objects even if they are more typing in simple cases. If you need to build up similar predicates for different database fields or form fields, you can easily parameterise your code and factor it in to helper functions or classes:

void AddFilterTextBox(IPredicateExpression filter, Control filterBox, CheckBox requireExact, TbUserFieldIndex field) { if (filterBox.Text.Trim() != String.Empty) { if (requireExact.Checked) { filter.AddWithAnd(PredicateFactory.CompareValue(field, ComparisonOperator.Equal, filterBox.Text.Trim())); } else { filter.AddWithAnd(PredicateFactory.Like(field, "%" + filterBox.Text.Trim() + "%"))); } } }

You then just need one line for each search field:

AddFilterTextBox(filter, RepFirstNameBox, RepFirstNameExact, TbUserFieldIndex.TbusFirstName); AddFilterTextBox(filter, FieldTwoBox, FieldTwoExact, TbUserFieldIndex.TbusFieldTwo); AddFilterTextBox(filter, FieldThreeBox, FieldThreeExact, TbUserFieldIndex.TbusFieldThree);

Also, you don't need to use filter.Add(...) first. Using filter.AddWithAnd(...) should work even when there is nothing added previously. (filter.Add(...) also defaults to AddWithAnd(...) if there is already something in the expression)

Regards, Ben

JimFoye avatar
JimFoye
User
Posts: 656
Joined: 22-Jun-2004
# Posted on: 27-Sep-2005 20:28:09   

Between the examples in the docs and on the forums, and intellisense, it's not as much work as it seems to code these predicate objects. Also check out the new beta, which uses operator overloading.