The correct divide and conquer

I have written something using Access.

Time passed, and it seems that Access won't do. I need something a little more serious - not just from the DB point of view, but from the UI point of view too.

So I did some thinking, and had an idea. As for now, I will leave the DB in Access. The UI - I need to change to PHP, Perl, VB or Delphi.

As you can see, everything is kind of still in the air and can change from time to time - the DB can be MSSQL, Access or anything else, and the UI can be PHP, VB, and so on.

I really do not intend to write everything from scratch for each combination (VB-Access, PHP-MSSQL, PHP-Access, etc) and these combinations are nessecary (so please don't try to talk me out of it - it's not the point).

Therefore, I want to divide the application into 3 major parts: the DB, the UI and the "engine" that connects the UI to the DB.
* DB - we all know what this part does
* UI - this part gets "requests" from the user and returns results to the user
* the "engine" - this part gets "requests" from the UI, talks to the DB and returns results to the UI

Please note that the engine is not ODBC/ADO/DAO/etc - it contains it, but its role is to connect the UI to the DB without knowing how and what language the UI is written in.

The advantage is that I can replace the DB and the UI parts as much as I want, but the "engine" will stay the same.

I know how to create the DB.
I know how to create the UI.
What I don't know is how to create the "engine" - how? what language is more suitable for this task? in what way? is it possible at all?

For example - if I write the "engine" as a DLL in VB (which is the prefered language because the application is in Access - VBA), will it be possible to use this DLL via PHP, Perl?
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!