Which is better, 1 large program or several smaller ones??

[ALSav]

Apologies for a rather niaive question but none of the VB books I have looked at deal in any depths with the issues of putting the final package together.

I have been working on a database package for about 6 months using Access 97, VB6 and Crystal Reports. The application, like many of database systems not only consists of forms for updating and viewing the data but also has a number of utilities for data analysis, generating mailing lists, generating HTML pages and queries and reports etc etc.

This is the first large-ish application I have packaged and would like to know if it is more efficient to have several small programs or one large one.

What is the maximum number of forms, designers, modules etc that a visual basic project can cope with before running into problems.

Are there any issues I should be aware of or can anyone direct me to a site/book that deals with this subject.

Thanks

 

[Terpsfan]

I don't know the exact numbers, but I don't think you'd have a problem with the number of forms and procedures you are creating in your application. I think it's better to keep everything in one project that way it is a lot easier to debug and maintain your application.

 

[chiph]

I've seen VB DLLs that are 8-10 megabytes in size with little speed penalty (they act as code repositories, and COM just calls the method it needs and ignores the rest).

In the case of an .EXE, load times could be affected if it got too big (the time it takes the program to initially appear on the screen). In which case you'd want to break the .EXE up into a framework, and have it call out to .DLLs as it needed.

I'd time how long it takes your program to appear on a typical user's machine, and see if it's too long for them.

Chip H.

 

[shepherd]

First off, there's alot to this question. The reason you probably have found little in the VB books on this subject is because this really isn't a VB question, but more a software architecture question - which is a huge topic on its own.

Generally, and especially when the application is as large and robust as the one you have described, you will want to break up the logical parts (based on function among other things). There are many reasons for this, such as scalability, maintainability, extensibility, reusability, etc. Your .exe file may contain all the user interface elements, while your .dlls may contain all the encapsulated logic. It would be difficult to list all the reasons you would want to do this, and there may be some (*few*) exceptions. But this would be a good general rule, as this is one of the main ideas behind COM architecture.

Dan Appleman has a few great books for VB programmers (and he's considered one of, if not the best in this area), and would be a good place to start. One book I'd recommend would be Developing Com/Activex Components With Visual Basic 6 (

http://www.amazon.com/exec/obidos/A...sr=2-3/ref=aps_sr_b_1_3/104-7242010-3716731).

Anyway, hope this helps - good luck.

 

[ALSav]

Many thanks for all your help. Looks like I'll be adding another book to my already over crowded bookcase!!