I think a lot of folks get hung up on this thinking that if you don't
use COM to access your 'business' object you're not really doing
n-Tier development. Technically that's probably correct, but logically
that's dumb... VCX classes, when you can use them are much more efficient
than COM dlls and should be the preferred way to access code *if* you
need a) local objects and b) objects that have access to VFP.

If you're breaking out your logic in such a way that *can* live independent
of any other VFP code then you're building your apps with n-tier in mind.
But that doesn't mean that you have to use it that way when local access
is available to you.

I typically use the following guidelines:

* Any objects that is a business object that should be exposed
it will get exposed as a COM object.

* If I can access that object locally via VcX I'll use the VCX
in the client implementation.

* If at some later point the object needs to be distributed to
another machine/app/system it'll be ready to go and only
the class CREATEOBJECT() needs to change (and you can even
fix that by using #DEFINEs for the class name.

The reason for this is simple: It's more efficient and cuts down
on binary model littering, as well as simplifying administration
and updates in most cases.

It helps in this scenario to test your objects both ways to make
sure the COM interfaces behave exactly like you expect (there are
few things like pathing etc to take care of).

+++ Rick ---


>Hi,
> I am wonder that we could build .dll file for implement the business logic to allow public access in 3-tier architecture. Why we put the business logic in .dll? May be it can be accessed by other application, if the logic was designed for an application only, do i still build it in .dll form or vcx? What is the comparison between both in any aspect?? What is the major purposes for each?
>Thank you