[AccessD] To framework or not?

Jim,

To extend your analogy, trying to assemble a trike from a pile of car parts would be a lot of work 
and would almost certainly fail without a ton of parts not included in the pile at hand.

There is certainly no free lunch.  My framework evolved from common stuff that I did for projects 
over the years.  In fact I have a stated agreement with my clients that they pay me by the hour for 
the work I do on their project.  If code that I write is generic and I can use it in my framework, 
then that code belongs to me (even though they paid me to write it) and I place it into my framework 
library.  If the code is specific to their application or could reasonably be considered a "trade 
secret" kind of thing, then the code belongs to them.

So while you are correct on all counts, the fact is that things don't go into the framework unless I 
find it useful over multiple projects.

Of course there is bloat, but that is also true for a plain old library.  Id a client doesn't want 
security then that doesn't get loaded or used even though it exists in the library.  In fact I use 
Framework SysVars to initialize the framework.  A sysvar can be something like:

VarName		VarVal
UseSecurity	True

Now my code that initializes the framework simply checks the sysvars.  If the client indicates they 
want security, I simply place a true in that SysVar and voila, security is available.  Security is 
one place where there is significant setup required to specify which forms use security, and which 
groups can use the various form capability.  Still, having the security written and in the framework 
as a service allows me to turn my attention to setting up the security of objects in the FE, not 
hunting around for how I applied security last time.

In general, frameworks provide services, and DotNet is a fine example of that.  Prewritten code that 
does a ton of stuff.  dotNet is not a framework in the same sense as I am discussing however. 
Windows or Linux is closer to what I am talking about.  A program that is always running that 
provides services to an application.

John W. Colby
www.ColbyConsulting.com


Jim Dettman wrote:
>    I think your opening statement is incorrect;  a pile of parts that can be
> made into a car is not a car - it's just a pile of parts.  It doesn't become
> a car until it's assembled.  Proof of point: I can dis-assemble a car into a
> pile of parts and then use those parts to make something other then the car.
> For example, I might make a trike.
> 
>   And a car once assembled can only function in one specific way.  That's
> the downside to frameworks; their rigid.  Upside is it makes them very easy
> to use.  
> 
>    Having to assemble a pile of parts every time I would want to go for a
> spin around the block would be difficult at best.   But if today I need a
> trike instead of a car, then having a car won't do me much good where as a
> pile of parts would. 
> 
>   Somewhere in between those two ideas is a balance.
> 
>   Personally I like frameworks for application level services (like your
> security system, menuing, logins, etc).  But all too often frameworks become
> bloated because they need to allow for variation in logic while still being
> rigid and that's their downfall.  You end up with a lot of code and overhead
> for things you may not need today, but might tomorrow (aka .Net)
> 
>   For example, the next customer that comes along may want security down to
> the field level, so you build that in.  But the next twenty want security
> only to the record level, or maybe not even at all.
> 
> Jim.