Re: Architecture ideas for n-tier app with diff backends

Peter,

Let me start by referring you to an excellent article written by Norman Judah, "Developing Applications for the Client/Server Model". It's available on MSDN, and covers the 4-layer model in detail.

Other remarks are interspersed....

Peter Daniels <peterd_at_snapsystems.com> wrote in message news:376FD2BB.D7758147_at_snapsystems.com...
> First, I want to thank all of you for getting involved. I like the 4 tier
idea and
> would like to discuss it further so I'm clear on the responsibilities of
each tier.
>
> 1) UI - we want this to easily move from a VB/VC++ front end to browser
based. In
> light of that, what is the interface language between this layer and the
Data
> Interface layer? We have pondered XML, but my knowledge of it is minimal.

Generally, the Data Interface and UI layers are very tightly coupled...an Access analogy would be that the UI is the form, while the DI is the code behind forms. In most instances, this implies that the UI and DI would be written in the same language.

Like you, I know very little about XML (it's on the "gotta learn this" list, but that's a _long_ list <g>). Based on my (very) basic understanding, however, I'd say that yes, the DI would be in XML if you're moving to browser-based technology. The closest I've gotten to this in my own experience is using ActiveX documents in a custom container, which isn't really very close at all, I'm afraid.

>
> 2) The Data Interface layer - So, there aren't really business rules
oprating here?
> This is the one I'm most confused about.

"Business rule" is a really slippery term. FWIW, the definitions I use are that an "Integrity Constraint" is derived from the relational model itself...so referential integrity and domain rules are integrity constraints. "Business Rules", on the other hand, are derived from the problem space...so a rule that determines a specific ordering of events or something like "the order can't be shipped until the customer's credit is approved" would be business rules.

Using these defintions, integrity constraints are handled by the DI layer, but business rules are not.

>
> 3) Transaction Interface layer - Is this where the MTS comes in? And, is
this where
> essentially all of the non-stored SQL resides? Are ALL of the business
rules
> encapsualted into this one tier?

TI components _can_ be implemented via MTS, but the model doesn't require them to be. Yes, the non-stored SQL would be built here. You might, for example, implement a TI component as an object that exposes an .Update method. When, say, Customer.Update is called by the DI layer (passing in the appropriate values), the TI component would build the SQL update statement and pass it to the external access layer for processing.

This, of course, is where the model gets messy. In theory, the TI layer should be independant of the database engine being used, but in practice, given the variations in SQL syntax, that can be difficult to pull off. In my own experience, I've almost always been able to get around this by pushing most of the processing to the db engine. This means you need to spend a lot of time building the db schemas for each of the engines you're supporting so that they can present a generic interface, but I haven't yet run into an application where that wasn't possible -- painful, occasionally, but always possible.

The TI layer also handles transaction management and error handling, btw.

>
> 4) External Access layer - if the TI layer builds the queries, what does
this layer
> provide? It seem like the SQL can go direct to the individual data
engines, or are
> these engine specific enhancemets, etc?

The EA layer actually executes the queries, and gathers the responses (either recordsets or errors). It is tempting to roll the TI and EA layers together, but there are advantages to keeping them separate. Since the EA layer doesn't need to know anything about the db schema, only the db engine, you only need one EA component for each db engine, no matter how many applications use it.

HTH

• Rebecca.