I'm working on a new generation of a half dozen apps or so, and they currently share a large set of framework libraries.
I'm thinking for the new generation to abandon this practice and maintain separate codebases.
The applications range from small to big, and while there is a relatively fixed number of applications, the number of installations and users is large and growing at a good rate.
Has anyone really dealt with this issue?
Mind sharing your experience and conclusions?
I've had occassions where I needed to maintain a customers app on an older version of VFE while enhancing and fixing bugs in the current version and I think it's a nightmare. I try to keep all of my apps on the same codebase. If not - welcome to VB programming. You end up doing a lot of cutting and pasting and pulling out of hair trying to keep the versions straight. - Mike Feltman
I concur with Mike Feltman. I think it's better to have conditional logic that makes the different behaviors you need dynamic, or use a factory, or some combination of these. Sometimes there's no getting around the copy/paste in certain situations, but I always try to avoid it if I can. -- Randy Jean
Think about this, in any "significant app" you're going to be subclassing nearly every framework class, whether its the application object itself, the user object, the data objects, the form and control classes, ect. The class hierarchies are very complex at this point, and you're functionaly married to alot of that complexity. If you're going to be creating that many classes right off the bat, and if this is a "significant app" (def: an important investment) why not attain the freedom from the large class hierarchies? How many lines of code are we talking about saving by reusing framework code accross apps? I've got some experimenting to do. -- Mike Helland
How many lines of code are you talking about saving by using a framework? If it's not thousands,
Click here! :) - Mike Feltman
Yeah, but code re-use is not just about saving lines of code. It makes unit testing easier, keeps things consistent, easier to maintain (esp. with multiple developers), etc. I guess if you decide you want to change something in your "half-dozen" apps and you don't mind searching & replacing things at least 6 times, then hey, it's your call. There are always times you have "app specific" coding that has to be done. It's really up to you as the developer to decide if something should be placed in the re-usable category or not. -- Randy Jean
I support the re-use of code across applications. When I look at the code that I reuse in the framework that I have created, most of the classes and procedure files are building blocks that don't get significantly modified or sub-classed in a new app. This leaves only a few that should be re-written to be app specific.
My advice would be to look at your framework and see what portion of the code really doesn't get changed or is changed little and which ones do get changed significantly. You may want to split up your framework logically into these two groups. Consider not using the framework for those classes that would be significantly changed in your new app.
Examples of framework code to possibly reuse:
Examples of framework code that may need to be excluded or re-written
- Enhanced combo and list boxes that allow adding new items to the list
- The baseclass library including the super functional form class
- Error handling and recovery classes
- Enhanced grid objects with column selection capability
- Export data and Import data classes
- DBF/DBC version upgrade and error recovery routines
- Data Environment, Cursor, and CursorAdaptor sub-classes may need to be customized extensively to confirm to new data environment you are working in
- Report initialization classes may be dramatically different in a new app
- Logon security and user ID management may be significantly different, especially at different companies
Of course your results may vary. But think in terms of what is and isn't worth re-using. --BenCreighton
"Data Environment, Cursor, and CursorAdaptor sub-classes may need to be customized extensively to confirm to new data environment you are working in"
Mmmmm, yeah... I'm going to have to go ahead and disagree with you on this. Of all tiers that SHOULD be abstract, the data tier is definitely one I would keep framework level for sure. This is where using a framework like VFE (which is totally 3 tier out of the box) will save tons of time. Or, look into Data Clas or Tightline Data Classes if that's the only layer of abstraction you really need. Either of these will pay for themselves big time even if you decide to go completely app specific on your presentation or business tier. Do you currently use a commercial framework or are you completely "roll your own"? -- Randy Jean
Randy - Please note the subject of this wiki is about evaulating an old framework and what to do with it. I am not advocating excluding data objects from a framework -- I am just giving an example that data objects may need to be upgraded or replaced (and therefore excluded from the OLD framework).
The world has changed over the years and we have FOXPRO native, ADO, SQL, XML or other potential data environments, so someone, somewhere MAY need to change things dramatically for a new app versus their existing framework. These are just POSSIBLE examples, not prescriptions. I would agree that having a universal data handling class structure is ideal, but not everyone has this capability in their existing frameworks from older applications. So guess what...they might have a data object that may need to be changed extensively OR replaced/bought to change their framework for building a new application.
What I proposed is a decision "framework" for evaluating an existing programming framework. Consider putting existing framework components into two logical groups (easy re-use VS. re-write/buy) to help facilitate making the decision to buy/create a new class (or set of classes) instead of using an existing framework class. --BenCreighton
Ben, I see. Point taken. And yes, I know the world has changed. I deal with data sources you don't even mention and do it all through a common set of data classes. That's really what I'm advocating, too. Maybe I misunderstood but I thought the subject of this wiki was about splitting the codebase across applications. Mike, are you asking whether you should temporarily split your codebase as you move some apps over to a different framework version? If so, that is usually an unavoidable issue. Unfortunately, we don't know anything about your current framework, how re-usable or nTier it is, etc. You say it's large and complex and you want to be "freed" from this. Maybe you're just not using a very good framework if it's that hard to deal with (you never said if it was your own, commercial, etc.) The VFE framework is fairly large, but the hierarchy is very simple and clean and not difficult to follow in my opinion. Are there a lot of classes that are included we never (or hardly ever) use? Yeah, probably. But if our EXE is a megabyte or two bigger, I really don't care.
I myself am forced to maintain apps in a few different versions of the VFE framework for different clients. Most of these would not be big projects to migrate or update to the latest, but unless there is a business case for it and unless we can get our clients to give us a budget for a purely "technical" update, we're stuck maintaining (or using) different framework versions. I particularly don't like this and wish all of our apps could be magically transformed to using VFE2005 (the latest and greatest version), but that's just not going to happen so we deal with it the best we can. -- Randy Jean
Contributors: Mike Helland
( Topic last updated: 2005.12.11 08:44:30 PM )