Where does business logic go?
We have a telephone ticket pricing application. We designed an object model and we have objects that have logic to decide how to price each ticket according to its characteristics and information from a database.
The customer wants to remove all the logic from the application and build up the logic from some configuration in tables in the database.
For example, now we have an object that knows that a certain charge varies its amount depending on which city the call ended. It is called Termination and the method getPrice() looks in the database the price it has for the city for every call it has to price.
Now the customer wants to specify all that explicitly in an external configuration. That means entering some way to determine when that paticular charge applies according to the information in the ticket, and also a way to specify when it is one or the other price.
That logic does not change in time unless there's a new law in the country. It only changes from country to country, for example, Termination does not exist in any other place but this country I'm talking about.
Is it normal to code generic "rule processing" applications or is it better to code the business logic itself?
We will do whatver the custiomer asks for, but I wanted to check your opinions.
Our idea is they will end up programming the pricing logic (very complex) with records in tables and we believe Java (or any programming language) is much more expressive for that purpose. :-)
[1524 byte] By [
fedetxfa] at [2007-10-3 8:37:59]
> We have a telephone ticket pricing application. We
> designed an object model and we have objects that
> have logic to decide how to price each ticket
> according to its characteristics and information from
> a database.
Okay.
> The customer wants to remove all the logic from the
> application and build up the logic from some
> configuration in tables in the database.
I can see using some of the data in the database to determine what to do with the data, but the "business logic" shouldn't go ANYWHERE near the database. The database is for 2 things, storing data and relating data, period.
> For example, now we have an object that knows that a
> certain charge varies its amount depending on which
> city the call ended. It is called Termination and the
> method getPrice() looks in the database the price it
> has for the city for every call it has to price.
>
> Now the customer wants to specify all that explicitly
> in an external configuration. That means entering
> some way to determine when that paticular charge
> applies according to the information in the ticket,
> and also a way to specify when it is one or the other
> price.
>
> That logic does not change in time unless there's a
> new law in the country. It only changes from country
> to country, for example, Termination does not exist
> in any other place but this country I'm talking
> about.
>
> Is it normal to code generic "rule processing"
> applications or is it better to code the business
> logic itself?
Either way, it's still business logic. In any case, it's better to code generic rather than hard code rules (that you'll have to update and recompile afterward).
> We will do whatver the custiomer asks for, but I
> wanted to check your opinions.
>
> Our idea is they will end up programming the pricing
> logic (very complex) with records in tables and we
> believe Java (or any programming language) is much
> more expressive for that purpose. :-)
Sounds like you either don't understand the requirements or "they" are on crack. I don't think I've ever seen logic programmed in records. Records store data. That said, there are stored procedures, which can execute logic inside the database, but (arguably) they should never be used unless you have a really nasty set of logic needed to be applied to lots of data (i.e. reporting)
