There's a bazillion ways to do this, but I favor a three-tier design in situations like this.
1. The first tier is the user interface. It contains the code that the end user sees and interacts with.
2. The second tier contains the rules that dictate how you want to interact with the data. For example, if the user interface has a login screen, perhaps each person has a different security access code. That way, one employee might have access to some data, but is denied access to other data. This tier enforces those rules.
3. The third tier contains the code that interacts with the data. The sole purpose of this tier is to service the second tier's request for (or edits to the) data. Even though you are working with multiple DB's or tables, I would put everything that talks with the business rules tier in this tier. This decouples the rules from the data server. The advantage is that you isolate the tiers so each becomes a "black box" to the other tiers. Therefore, if you make changes in the data tier, the rules tier need not even know about it.
(WARNING: Ad to follow)
My C# book designs and implements a simple card game in Chapter 10. The user interface is what the player sees (tier 1). The second tier contains the rules for the game (which includes betting), and the third tier is the data server. In this case, rather than being a DB, the data server tier is a deck of cards, with methods for creating the deck, shuffling it, and dealing out cards, etc. While your problem is not a one-to-one match, it can be modeled as such.
I hope this helps...
Dr. Purdum
Jack Purdum, Ph.D.
Author: Beginning C# 3.0: Introduction to Object Oriented Programming (and 14 other programming texts)
|
