This is definitely an option that's open to you...I know of several companies with large applications that have divided up their application this way. There is one caveat with this approach...sometimes VFP cannot find a class in an external library even when you're doing everything right (yes, this is a bug!). You have to move the "offending" class into the main project to get it to work! If this doesn't bother you, then you may want to take this approach.
>How would I control building the "fat" main and "thin" secondary apps?
"Control" from what perspective?
>What is an overview of how to have the abstract factory integrate all the seperate applications into one big accounting application?>
Basically, your main project will contain the Framework classes, and your sub-projects will contain only the classes that are specific to the particular module. When you build the sub-project VFP will pull in the parent classes it needs (including Framework files). You can simply exclude these from the sub-project and recompile again. They're not necessary because the classes located in subprojects that you instantiate from the main project end up inheriting from the Framework classes stored in the main project.
<>
You should definitely start off by testing your business objects from the Command Window...this ensures that you have no application logic in the user interface and everything you need is in the business object. Aside from that, you can test the application as you normally would--with all the pieces integrated.
Regards,
Kevin McNeish Eight-Time .NET MVP VFP and iOS Author, Speaker & Trainer Oak Leaf Enterprises, Inc. Chief Architect, MM Framework http://www.oakleafsd.com
