Fat Client to n-Tier

Currently our program has all user services, bussiness rules,
and data services in the executable on a file server. The
database is SQL 2K on another server. What would be the best
design for this program? Employee time, client and project
management, billing, and reporting currently in this program.
More adds than updates. Something like User services and some
bussiness rules in the executable and create some new dlls to
perform the rest of the bussiness services and another dll to
perform data services?

Thanks for any input.

Quote:

---

Originally posted by RobDog888
Currently our program has all user services, bussiness rules,
and data services in the executable on a file server. The
database is SQL 2K on another server. What would be the best
design for this program? Employee time, client and project
management, billing, and reporting currently in this program.
More adds than updates. Something like User services and some
bussiness rules in the executable and create some new dlls to
perform the rest of the bussiness services and another dll to
perform data services?

Thanks for any input.

---

I'd say yes and no. The executable sitting on the client should deal with your basic interface with little or NO business logic whatsoever. You will want objects (classes) for each entity in addition: customers, products, users, etc.

Try to seperate entities on about 2-3 classes. One class generally being the object itself (the entity, one customer, one user, one object). The second class should be a grouping of these objects with some functions for pulling and manipulating the data. You may have one additional class as an object collector (collections). This ensures that objects are wrapped into a collector and spit out when needed.

You can include functions to count, index, or display these user defined types as well. The drawbacks to a typical client-server application is that modifications are a bi*** if you need to change something, and there is hardly any reusability :cry: . Trust me I feel victim to it. I think Woka instilled it into my head that the way to go is levels or tiers. Seperate the gui from the business logic from the database.

VB Code:

__________________
                      [ THE BIG SQL SERVER ]
                      ------------------------------
                               ^   ^     
                            dll activex dll...(talks to db, db talks to dll)
                              ^^
                              ........
                             client (talks to dll, dll responds)

Van Gogh at his finest :(

Thanks for the direction. I forgot to mention that
the users are accessing the exe by way of a shortcut. Would this
be detrimental to performance or a benefit?

Thanks

Here's a small 3 tiers app.
Only loads the data.
It's merely a proof of concept demo.

The 3 tiers are:

• User Interface EXE
• CLient Objects DLL
• Server Objects DLL

The Server DLL, in this demo it's called vbPropertyBagServer, does all the DB work. This is the ONLY project that references ADO, and hits the DB directly. The DLL can sit on a server, or on the client PC. This is where you would have your business rules.

The Client DLL, is an interface for the EXE. This DLL exposes objects and thier properties to the user interface. This DLL usually sits on the Client PC

The UI EXE is the main app. This references the client DLL, and therefore doesn't care about the server DLL, or it's ADO or anything for that matter. In fact, you could change the server DLL to save the data into a txt file, and the UI EXE and client objects wouldn't even know about it. That's the beauty of n-teir design.

There are many methods or passing data between tiers. I use property bags, but am working on some code that'll do it in XML. XML is just much neater than using property bags, but it does mean you have to have an extra XML dll on your pc, unless you write your own XML parse.
Another method is to use ado recordset, but I do not like this idea :( And have stayed well clear of it, but other developers swear by it, but each to their own I suppose.

One of the main benefits of designing an app like this, apart from each tier is seperate and doesn't care what the other tiers do, is the fact your EXE is now very small indeed.

This means that when you load your app it only takes up a little bit of memory. It only loads the "code" (DLL) when it needs to, when the object is destroyed then the memory is cleared.

Does this make sense?

Woof

Poo...forgot the app. Boooooooooo

Here's 2 very small demo apps that show you how property bags are used to send flat data or parent child data between tiers.

Hope this helps.

Woka

Sorry for the delay, but I have been remodeling our house. New
roof, very busy and tired.

Thanks for the examples. I will look at them and let you know.
Yes, this is starting to make allot more sense.

I'll be back!

very nice code, should be at code bank