Hi. I would like Otis' and the forum's opinion on this feature:

• Have LLBLGen generate code enumerations for designated lookup tables.

Say for example that there is a Countries lookup table with a CountryID PK and CountryName field. This table is practically static for the application and is used as FK in many other tables, so it would be useful to have an enum like this:

enum Country { ... Mexico = 56, Panama = 57, ... }

The client code would be able to do this:

CustomerEntity c = new CustomerEntity(); c.Name = "ABC"; c.CountryID = Country.Mexico;

instead of hardcoding the ID 56, or querying the DB to retrieve the country by name. The enum produces clean and efficient code.

Ok, and the data for an enum has to be pulled from the db? Or do you also want to add simple lists by hand?

Unfortunately not possible unless the Enum structure would only be changed by doing a refresh of the schema and then rebuilding the LLBL project

Otis wrote:

Ok, and the data for an enum has to be pulled from the db? Or do you also want to add simple lists by hand?

Yes, from the DB. In the designer I could specify which are the lookup tables and the ID, Name fields and the template would create a file similar to ConstantEnums.cs, e.g. LookupEnums.cs and add it to the DAL project.

Not sure what you mean 'simple lists by hand'.

Unfortunately not possible unless the Enum structure would only be changed by doing a refresh of the schema and then rebuilding the LLBL project

I think he is referring to things that dont really ever change, like the states in the US, this would be really handy for that.

Even so, if you added a 51st state, for instance, you could just add another value to the enum with that states ID in the db.

Answer wrote:

Even so, if you added a 51st state, for instance, you could just add another value to the enum with that states ID in the db.

which means you have to distribute a new build if a state is added, i'm sure your clients would love that

obzekt wrote:

Otis wrote:

Ok, and the data for an enum has to be pulled from the db? Or do you also want to add simple lists by hand?

Yes, from the DB. In the designer I could specify which are the lookup tables and the ID, Name fields and the template would create a file similar to ConstantEnums.cs, e.g. LookupEnums.cs and add it to the DAL project.

I'll think about it

Not sure what you mean 'simple lists by hand'.

Adding the name-value pairs by hand in a form

netclectic wrote:

Answer wrote:

Even so, if you added a 51st state, for instance, you could just add another value to the enum with that states ID in the db.

which means you have to distribute a new build if a state is added, i'm sure your clients would love that

If you are using the application updater block that shouldn't be an issue.

I have a Taskperformer that does this or something very simular.

In the config file you specify the tables that you want to be enumerised the value field, description field , enum type - char or integer and the file destination. It is very basic but gets the work done.

It only works with SQL Server but you should be able to modify the code very easily for oracle and firebird.

I will try and clean it up and give it to otis to post on the 3rd party section.

wayne wrote:

I have a Taskperformer that does this or something very simular.

In the config file you specify the tables that you want to be enumerised the value field, description field , enum type - char or integer and the file destination. It is very basic but gets the work done.

It only works with SQL Server but you should be able to modify the code very easily for oracle and firebird.

I will try and clean it up and give it to otis to post on the 3rd party section.

I use lookup tables in my apps too. However for me, I almost always bind them to comboboxes. So you can bind the ID field to SelectedValue property, and the Text property to the country field. It was just as easy if not easier that way. Can you give an example of another way in which enums might be better? Maybe in the BL Layer?

I use lookup tables in my apps too. However for me, I almost always bind them to comboboxes. So you can bind the ID field to SelectedValue property, and the Text property to the country field. It was just as easy if not easier that way. Can you give an example of another way in which enums might be better? Maybe in the BL Layer?

This should actually be under architural section...

Binding the tables are not a problem - as that is a good solution to use in interfaces but in BL Code you don't have that luxery and often in your BL you need to know what the value of a certain field represents. What is PaymethodID 1?

Paymethods do not change that often so they are a good example of lookup values that could be enumerized.

For example Paymethods: 1. Credit Card 2. Debit Card 3. Cheque.

I use enums when i have to do a certain something when a payment transaction happens.

if Ordertransaction.paymentID = Paymethod.creditcard then
else
  if Ordertransaction.PaymethodID = Paymethod.Debitcard then
  endif
endif

If you did not have enums for PaymethodID then you would have had to hard code the value or you would have had to hard code the description and then lookup the Value part for the matching description.

I found it usefull to have enums for lookup table values that do not change that often - especially system settings like employee maritial status, titles, security groups ext.. but the choice of which lookuptables to enumerize must be made carefully. Seeing that you don't want to release a new version just because you added a new Bank Branch.

wayne wrote:

I use lookup tables in my apps too. However for me, I almost always bind them to comboboxes. So you can bind the ID field to SelectedValue property, and the Text property to the country field. It was just as easy if not easier that way. Can you give an example of another way in which enums might be better? Maybe in the BL Layer?

This should actually be under architural section...

Binding the tables are not a problem - as that is a good solution to use in interfaces but in BL Code you don't have that luxery and often in your BL you need to know what the value of a certain field represents. What is PaymethodID 1?

Paymethods do not change that often so they are a good example of lookup values that could be enumerized.

For example Paymethods: 1. Credit Card 2. Debit Card 3. Cheque.

I use enums when i have to do a certain something when a payment transaction happens.

if Ordertransaction.paymentID = Paymethod.creditcard then
else
  if Ordertransaction.PaymethodID = Paymethod.Debitcard then
  endif
endif

If you did not have enums for PaymethodID then you would have had to hard code the value or you would have had to hard code the description and then lookup the Value part for the matching description.

I found it usefull to have enums for lookup table values that do not change that often - especially system settings like employee maritial status, titles, security groups ext.. but the choice of which lookuptables to enumerize must be made carefully. Seeing that you don't want to release a new version just because you added a new Bank Branch.

Thats what I was thinking for comparing values in the BL. I guess enums could be pretty nice for that.

I am using adapter. In my BL I have an EmployeeManager class, with a GetEmployee method that returns an employee entity. In my PL I required checking the employees role, which has a FK to the Role table. In my PL I didn't want to do

if(employee.Role = 1)

Sooo I wrote in my BL to fill the Role Entity as well. So now GetEmployee returns the employee, with the relation to Roles filled. So now I have something like this

if(employee.Role.Description == "administrator")

Using enums in this case would be nice if your forgot the different roles an employee could have. Plus autocomplete is nice Also, not having to do the extra coding in the EmployeeManager class could have been avoided, as writing the extra code to fill a Role Entity in the EmployeeManager class gets confusing/messy as your relations get deeper and more complex.

Yah - it would be much nicer to rather use enums in the security profile role than string comparing

If you want the Taskperformer that generaters a enum file for you... You can get it from here until Otis has had time to upload it to the 3rd party section.

ftp://196.36.190.121/LLBLGEN/TaskPerformers/EnumTaskPerformer.rar
Username : llblgenguest
Password : treeboat

wayne wrote:

Yah - it would be much nicer to rather use enums in the security profile role than string comparing

If you want the Taskperformer that generaters a enum file for you... You can get it from here until Otis has had time to upload it to the 3rd party section.

ftp://196.36.190.121/LLBLGEN/TaskPerformers/EnumTaskPerformer.rar
Username : llblgenguest
Password : treeboat

Thanks Wayne, You the man.

Just curious

Your code generated this:

public enum RoleType : int
    {
        Administrator = 1,
        User,
        Guest
    }

I use it and still have to cast to int like this

if(_employee.FK_RoleId == (int)RoleType.Administrator)

The base type was set to int. So why do you still have to cast? Even on the MSDN examples they have it cast after the base type was declared. Does anyone know why? If so, what is the point of declaring the base type?

MSDN's Example:

public class EnumTest 
{
   enum Range :long {Max = 2147483648L, Min = 255L};
   public static void Main() 
   {
      long x = (long) Range.Max;
      long y = (long) Range.Min;
      Console.WriteLine("Max = {0}", x);
      Console.WriteLine("Min = {0}", y);
   }
}

Nevermind, MSDN explained it:

The underlying type specifies how much storage is allocated for each enumerator. However, an explicit cast is needed to convert from enum type to an integral type. For example, the following statement assigns the enumerator Sun to a variable of the type int using a cast to convert from enum to int:

int x = (int) Days.Sun;

Wayne, have you tested char for enum type? MSDN says this:

base-type (Optional) The underlying type that specifies the storage allocated for each enumerator. It can be one of the integral types except char. The default is int.

In your documentation you have:

1. EnumType_X is the type of enumerator int or char.

No - i havn't used the char type - sorry i thought it was possible to use char...seeing that you could use char in other languages becuase its base is of type byte - well it use to be...havn't checked what it is in dot net.

The type can actually be anything - as you specify it.

PS - I added http support - http://196.36.190.121/LLBLGEN/

wayne wrote:

No - i havn't used the char type - is something wrong with it?

The type can actually be anything - as you specify it.

PS - I added http support - http://196.36.190.121/LLBLGEN/

MSDN says you can't use a char type, only integral.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemenumclasstopic.asp

Read under remarks.

sorry i thought it was possible to use char...seeing that you could use char in other languages becuase its base is of type byte - well it use to be...havn't checked what it is in dot net.

wayne wrote:

sorry i thought it was possible to use char...seeing that you could use char in other languages becuase its base is of type byte - well it use to be...havn't checked what it is in dot net.

Its not a problem. I wasn't trying to use it. I just wanted to let you know so when Otis puts it in third party downloads he doesn't get people bitching a fit about it

Bitching about 3rd party stuff is flushed through to the original authors.

Wayne, thanks for the performer! I'm testing it now but get exceptions ("SQL Server does not exist or access denied") so it seems that there is a problem with the connection string. I have no problem refreshing the catalog and generating the regular code though using the built-in templates. Any ideas?

You should open your LLBLGen project. The select the generate - select the task performer then generate. The connection string is retreived from the project - i have no control over that.

hmm...maybe Otis is no longer storing the username and password...I know he was talking about security issues...The task performer works with the 28th June release. If that is the case - i will release a patched version. Please give me some feedback.

wayne wrote:

You should open your LLBLGen project. The select the generate - select the task performer then generate. The connection string is retreived from the project - i have no control over that.

hmm...maybe Otis is no longer storing the username and password...I know he was talking about security issues...The task performer works with the 28th June release. If that is the case - i will release a patched version. Please give me some feedback.

Mine worked but I was using the June version. I just upgraded and havn't checked.

wayne wrote:

hmm...maybe Otis is no longer storing the username and password...I know he was talking about security issues...The task performer works with the 28th June release. If that is the case - i will release a patched version. Please give me some feedback.

That must be it, because I'm using July/12. Thanks!

Btw, is there a way for the generated enum.cs file to be added to the DatabaseGeneric project?