Hi,
This is probably a very basic question, but a solid answer from someone else in the forum could save me weeks of heartache.
I'm working on a project that would automate the generation of various legal forms based on user response to various questions. Within each form, the answers to certain questions will alter the questions that are asked. This is simple stuff and relatively easy to code. However, because the rules change down the road, the system needs to be flexible enough to support easy changes to the business logic in the future.
I'm imagining that this could all be handled -- including the business logic -- within the data layer with a group of related tables. Each form would, of course, be its own table. Each form table would be composed of a series of fields, including fields for boilerplate content and fields populated by the user response to various questions. Each form table would also include a link to a unique table that contains the business logic (essentially an abstracted logical sequence) for that form
My questions are: (1) Is it bad practice to have the business logic buried in a database table in this way? (2) Is my conceptualization flawed? I'm wondering if I should create a class called legalForm and then have each of the specific forms exist as instances of that class. My problem with this approach is the fact that each form object would have a different combination of fields and properties, which could create massive headaches.
Look forward to any guidance that people might provide. If you can point me toward existing examples of something similar, I would be very grateful. Seeing this type of thing in action is often enough to make the light-bulbs go off.
Thanks!
Carbonel
This is probably a very basic question, but a solid answer from someone else in the forum could save me weeks of heartache.
I'm working on a project that would automate the generation of various legal forms based on user response to various questions. Within each form, the answers to certain questions will alter the questions that are asked. This is simple stuff and relatively easy to code. However, because the rules change down the road, the system needs to be flexible enough to support easy changes to the business logic in the future.
I'm imagining that this could all be handled -- including the business logic -- within the data layer with a group of related tables. Each form would, of course, be its own table. Each form table would be composed of a series of fields, including fields for boilerplate content and fields populated by the user response to various questions. Each form table would also include a link to a unique table that contains the business logic (essentially an abstracted logical sequence) for that form
My questions are: (1) Is it bad practice to have the business logic buried in a database table in this way? (2) Is my conceptualization flawed? I'm wondering if I should create a class called legalForm and then have each of the specific forms exist as instances of that class. My problem with this approach is the fact that each form object would have a different combination of fields and properties, which could create massive headaches.
Look forward to any guidance that people might provide. If you can point me toward existing examples of something similar, I would be very grateful. Seeing this type of thing in action is often enough to make the light-bulbs go off.
Thanks!
Carbonel