[AccessD] Framework Discussion - Another poll

I have not been active at all in this thread but have been lurking on it as I always do.

I've moved on from Access to Enterprise Applications where almost everything is data driven - Siebel being my latest gig.  I remain a member of this list because of the discussions and ideas which are commonly generated here.

Siebel (and SAP, PeopleSoft, take your pick) is basically a big data driven framework on a large scale, yet similar to what you are implementing and discussing.  Working with it and other apps for the past few years has given me a lot of ideas on how software could be implemented and structured within frameworks or common code sets in other applications, most notabily Access since that was my first platform.

If I ever go back to 'ground-up' development, I'll definately create a framework of a type to make things as non-repetitive as possible.  

I have not done a lot of digging into your framework but I know this - your framework works for YOU.  Just like my framework would work for ME.  You may hear that people don't want to use your framework and that is fine.  However, I still like to read the discussions because I'm more interested in the ideas behind it and how it is implemented.

So please continue your writeups and discussions.  Even if it isn't used by others, the discussions may still spark ideas.

Mark



> -----Original Message-----
> From: Arthur Fuller [mailto:artful at rogers.com]
> Sent: Wednesday, March 24, 2004 4:10 PM
> To: 'Access Developers discussion and problem solving'
> Subject: RE: [AccessD] Framework Discussion - Another poll
> 
> 
> I am, but admittedly with reservations. Back in the dinosaur 
> age I wrote
> a lot of stuff vaguely similar, and subsequently discarded for
> performance reasons. That was back when all you could count 
> on was 640K
> or maybe 1MB of RAM. But perhaps the analysis still obtains. 
> 
> As I see it, there are two poles:
> 
> 1. Write everything O-O and have the framework figure out 
> what to do at
> run-time.
> 
> 2. Regen the entire app so nothing has to be figured out at 
> run-time and
> everything will therefore perform much more quickly.
> 
> I'm not yet sold either way. Or perhaps more accurately, I am sold one
> way or the other depending upon the app's requirements. Given 1000
> users, development time is trivial compared to execution 
> time. Given 10
> users, development time is much more significant. IMO, if 
> performance is
> paramount, data-driven doesn't cut it. But there are lots of apps in
> which performance is not paramount, and in that case 
> data-driven may be
> the right way to go.
> 
> I wrote a lib a long time ago which was based on data-driven tech.
> Turned out the California Red Cross was one of our biggest 
> customers. In
> their context, the performance-hit for data-driven was a serious
> problem. Heart-pacers were at stake, and various other machines. Any
> possible performance-hit had to die, else some patient might. 
> 120 users
> to start, it later got a lot bigger; seconds mattered big time: every
> fraction of every second mattered big-time.
> 
> Not to say every app is like that. Just to say that I have learned the
> hard way that when performance is paramount, data-driven 
> loses. When it
> is not paramount, data-driven wins pretty much hands down.
> 
> My $.02.
> 
> Arthur
> 
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of 
> Gustav Brock
> Sent: Wednesday, March 24, 2004 1:56 AM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] Framework Discussion - Another poll
> 
> 
> Hi John
> 
> I do.
> 
> /gustav
> 
> 
> > I need to take another poll.  Would everyone following the 
> discussion 
> > please raise their hands.
> 
> -- 
> _______________________________________________
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 
> -- 
> _______________________________________________
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>