I know that I'm going to ask a very general question, but, since I'm
looking for concrete and language-specific answers, I hope that someone
out there will help me.
I'm going to develop an application using VB 5 Pro, and I'd really like to
apply the logical design based on the separation among user services,
business services and data services, even though the physical design will
be a simple ".exe + .mdb" installed on the same machine, and operated by a
single user.
The reason why I want to apply this design approach is because the
application should be easily scalable for a multi-user, intranet
environment. I know that I should move to an Enterprise edition to build a
client/server edition of my software, but still I don't want to apply any
major change to the logical structure of the application the day it has to
be ported on a client/server environment.
Now, I understood how to translate into VB the distinction between user
objects and business object, but I'm having problem in finding the "VB
translation" of the distinction between business objects and data objects.
How can I describe a business object that is independent from the database
structure, and a data object (based on DAO) which works as an interface
between the business object and its database sibling?
Instinctively, I'd put the "Write" and "Read" methods in the business
object, but how can those methods be database-independent?
The only document on the Internet that gets near to an answer to my
problem is at http://www.microsoft.com/devnews/devdays/scalarch.htm, but
I'd like some more (and/or better) examples, if possible.
Thanks in advance to everyone who will help me.
Bye for now,
Giovanni
--
Cláudio Avolio Rodrigues
IBM Global Services
Systems Specialist
E-mail: avo...@unisys.com.br
http://www.c-avolio.com/vb
Actually there is some very good info in the online books supplied with
vb50.
Check out the "Guide to Building Client/Server applications with Visual
Basic"
You have allready learned a valuable lesson just considering to divide your
application among user services, business services and dataservices.
The design principles for building a simple exe file is quite different
compared to building a distributed Client/server project because you will
have to deal with performance issues, creation of proper interfaces between
the components and so forth.
You will most likely look at a rewrite of the program, with possible reuse
of some subs and functions.
The "right" way to do what you want is to use the Enterprise VB from the
start, create all the components, register all components on a single
machine and run them there. It is then very easy (if you use NT4's) to
distribute and run some of the components on other machines.
If you just want to make a simple exe I sugges you create a module that
"own" the database + all the functions to access them.
Option Explicit
' Path to database
Private strDBPATH As String
Private dbDB As Database
Private wrkJet As Workspace
' Make some functions to open Workspace, create connection and so forth
' Make some functions/subs to insert/retrieve data in the database
By only accessing the database through functions/subs it is easyer to create
a Database service in a separate component at a later time.
Before you begin to start building C/S apps, I suggest you do some heavy
reading of the online books regarding components, and make sure you know how
to build error handling routines that a very robust (a funny acting
distributed component is not funny)
Good luck.
Regards
Jakob Leander
Euros <eu...@interbusiness.it> wrote in message
euros-15099...@192.168.0.2...