tags:

views:

206

answers:

4

we want to implement business logic based on records in a table. We have two choices.

One way is to create an enum in code for each record in the table and in code compare the enum with the read record to decide what logic comes next. A drawback with this system is that if the key changes in the table(for example in autonumber fields), the application needs to be recompiled to reflect changes.

A second way to do this is to store variables in a configuration file for each record in the table, and in code compare the config variable with the read record to decide what logic comes next. A drwback with this system is that the config file could be manipulated and the application will stop working.

What is the best programming pattern for this matter?

+2  A: 

Why not keep it all together and put a table in the database that tells you which business record table comes next?

Sorry, I can't give a better answer. I need more info on what things your business logic is trying to do, and what orders these records can be in.

Scott Langham
+1 This is a reasonable alternative
Robert Kozak
+1 sorry I did not undestand your answer..
Igor Zelaya
but is is also a way to go
Igor Zelaya
+1  A: 

I favor your first approach. If the logic changes sufficiently to require a change to your autonumber field (either by deleting an old record, or adding a new one), you are going to have to change the code anyway to reflect the new paradigm.

Robert Harvey
A: 

Enums should be static and unchanging. If you have a solution that requires change to an enum then enums are the wrong solution.

An external config does suffer the problems you mentioned so it is not always a good choice either. To help with this you could encrypt it so it is not easily modifiable.

Another alternative would be to create a resource dll that has the config file as a resource so it is not easily modifiable. When you do need to make a change you only have to compile the resource dll and deploy that only and not the entire app.

Scott Langham mentioned using a configuration table in your database. This also is a good idea. Is this possible with your setup?

Robert Kozak
A: 

It sounds like something like State pattern. I imagine that you have a table that stores states (ID, Name) and logic associated to each one in your application. Given a state ID, given the logic you have to execute. You have to solve how to instantiate the correct state, if you're using an ORM you can use a discriminator (the state ID in this case).

bloparod