|Refactoring a "runtime" language firstname.lastname@example.org (2004-01-16)|
|Re: Refactoring a "runtime" language email@example.com (Alex McDonald) (2004-01-17)|
|Re: Refactoring a "runtime" language firstname.lastname@example.org (2004-01-18)|
|Re: Refactoring a "runtime" language email@example.com (2004-01-22)|
|Re: Refactoring a "runtime" language firstname.lastname@example.org (Alex McDonald) (2004-01-22)|
|From:||"Alex McDonald" <email@example.com>|
|Date:||17 Jan 2004 23:28:45 -0500|
|Posted-Date:||17 Jan 2004 23:28:45 EST|
"Nano Newbie" <firstname.lastname@example.org> wrote ...
> I have never looked at anything like this before. Given this
> information, does anyone have any recommended resources, such as books
> (especially), websites, tutorials, code (free), algorithms, similar
> languages, and so on that might be useful.
> I was looking at some compiler design books, but I am thinking there
> might be more specific resources than this???
The first action should be to get a good book on client/server
application design; the system you describe confuses 3 layers of
functionality that should really be separate. Just as factoring long
monolithic stretches of code into more manageable functions with
defined inputs (parameters) and outputs (return values) is desirable
for ease of writing, testing and maintaining code, a good systems
design does exactly the same factoring. The "classic" layers of this
kind of application are;
First layer; data management. Getting/putting data to the database
system should be cleanly defined, with interfaces to the SQL database
on the left (think of a left to right diagram with the data leftmost
and the user rightmost) and the interfaces to the next layer (business
rules) on the right.
Second layer; business rules. Ensure that the data (such as you
example of total < 100) is consistent and makes sense. Leftmost side
is the interface to the data abstraction layer, rightmost is the
interface to the presentation layer.
Third layer; presentation layer. Where to place data on the screen,
how to handle input, errors etc.
With the layers separated out, you can then do things like; make the
presentation layer a Web browers or VB or another piece of software;
change databases, say MS SQL Server to Oracle; maintain business rules
without affecting anything else; insert transport & data
transformation mechanisms between each layer (such as message
queuing); and scale you application. For instance, the improved
scalability would allow your application to have a database on server
A, B and C, business rules on server D and the presentation layer on
load balancing webservers E, F and G. As a note, many applications
designers find XML useful as the lingua franca between layers.
Once that's done, then choose your poison to implement; and because
each layer is now separate, you can choose the best tool for the job.
Return to the
Search the comp.compilers archives again.