At 12/27/2004 02:59 PM (Monday), Peter Welch wrote:

>I'm all ears, Doug. Have you an example of how to do as you propose,
>or a reference/link on the net?

Actually, no, I don't. I'm still trying to figure it all out myself.

>I think what's anemic is my understanding of ASP.NET and web
>programming. With Client/Server applications I can well see the value
>of the extra layer. But with the web, I don't know how I'd get one
>ASP.NET app to serve data to another.

I don't think the app server is an ASP.NET app. It is a service which runs
alongside the DB and interfaces with ASP.NET apps. No user interface at all.

Actually, to be honest I don't even know what an ASP.NET application is. I
have an allergy to "web apps" and I think they are a perversion, so I have
done little to keep up with their evolution. I guess I'm the wrong person
to talk to if that's what you are building!

>And, anyway, I thought that was the point of the 'code behind' stuff -
>to separate the server code from the client page (application?).

My understanding of the current ideal structure is:

Think of the DB as a pure data store. Only enough smarts to keep up the
data integrity and coordinate access from multiple agents.

The app server is where the business intelligence is located. Knowing what
relates to what and in what way. (The data store needs to mirror some of
this, of course.) Most access to the data is done through the app server
but there could be more than one for performance reasons.

The user-facing code is mainly just display and submit. Some validation is
here to make life easier for the user. Anything complicated gets pushed to
the app server via a request for processing.

Anyway, this is off topic for firebird-support list.