Thanks to everyone for the most useful advice I got in the node
. Hopefully, I am not imposing
too much on the Monastery by ask for some more wisdom.
The project I am working on involves acquiring data from various systems
and put it into a database, so that a set of business rules
can be run
against the data. The results of the business rules are stored in the
database and reports are generated.
The questions I have are this:
- Since we have business rules should the architecture of the system
- And if we will have middle-ware does the architecture have to be N-tiered?
- What languages should the middle-ware be written in?
- Would the middle-ware contain the business objects?
- The original "developer" implemented the business rules in PL/SQL and triggers.
Is this a bad thing?
- I feel that our "team" should only be responsible for the back-end
and the middle-ware so do we need to be concerned about model/view?
- Is the back-end basically a data warehouse and when combined with the middle-ware
does this constitute a data mine?
- Should the business-objects contain the SQL to extract the data and manipulate it,
then store that resulting data back to the database, or should the business objects call
store procedures to do this?
- I am using terms correctly?
- What is a Business Rule?
- What is model/view?
- What is a data mine and a data ware house?
- And last but not least what set of documents are typical for a small developement team that is developing a N-tiered system?
And of course how can I sell my boss on using Perl for parts of this system?
I would hate to get stuck using .NET or J2EE. :)
Or should I be more open minded about these platforms
I meant to say model/view
not client/model view
thanks to tilly
for pointing that out to me.