Sorry for the double post in Architecture, didn't see the "General" Topic.

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

I usually place searches into a search class. Using this search class we then define the properties that will be used in the search and then call the search method of the class that returnes and entity or typedview. That way you use the form logic to determine which properties to set and then call your search. Here's an exmple

public class EmployeeSearch
{
   #region fields
   string _lastname = string.Empty;
   string _firstname = string.Empty;
   int _employeeid = -1;// this just needs to be a value that would never be used
   #endregion

   #region Properties
   public string LastName
   {
      get { return _lastname; }
      set { _lastname = value; }
   }
   public string FirstName
   {
   get { return _firstname; }
   set { _firstname = value;}
   }
   public int EmployeeID
   {
      get { return _employeeid;  }
      set { _employeeid = value; }
   }
   #endregion
   #region methods
   public EmployeeCollection Search()
   {
      IPredicateExpression pe = new PredicateExpression();
      if (_employeeid != -1)
      {
          pe.AddWithAnd(PredicateFactory.CompareValue(EmployeeFieldIndex.EmployeeID, ComparisonOperator.Equal, _employeeid));
      }
      if (_firstname != string.Empty)
      {
          pe.AddWithAnd(PredicateFactory.Like(EmployeeFieldIndex.FirstName, "%" + _firstname+ "%"));
      }
      if (_lastname != string.Empty)
      {
          pe.AddWithAnd(PredicateFactory.Like(EmployeeFieldIndex.LastName, "%" + _lastname+ "%"));
      }
      EmployeeCollection emps = new EmployeeCollection();
      emps.GetMulti(pe);
      return emps;
   }
   #endregion
}

You get a rough idea of how we about setting up a search class and then in all of our forms that need to do employee searching we can define as few or as many properties as we want and get back our employees fairly easily. Of course the filtering is less verbose in version 1.0.2005.1 so that may make this solution less desirable. It's definately not 10 lines, but it's served our purposes so far.