[Zope] Multi tier partitioning meaningful in some Zope apps ?

[Nitin Borwankar]

All,

After struggling for a while with all of the parts of the Zope framework
in all it's complex and stark beauty a light seems to have gone off
inside.

Does the foll "application architecture" make sense

Function        Zope                 Tier                (analogous)
========        ===============   ==============         ===========

Visual          -> DTML-Docs      -> Light Middleware    (JSP-like
visual+some logic)

Biz Logic       -> DTML-methods   -> Heavy Middleware    (EJB-like
non-visual all logic)

Data Access     -> ZSQL-methods   -> Data API            (JDBC-like)

This stretches the truth somewhat especially in comparison to Java
technologies.
(EJB focuses on transactions a lot, with the intention of making them
transparent).

And of course Zope offers other component technologies that this does
not encompass, but is this a viable way of 

a) Thinking about application architecture for the first set of apps
while
   learning Zope ?
b) Actually developing apps ? 
c) Partitioning tasks for distribution across skill sets ?

I understand this will need addition usage conventions so as to 
"reduce the degrees of freedom" in Zope to a manageable subset for this
"methodology" - such as :-

"Use REQUEST['fieldname'] to extract data in the middle-tier
and then call ZSQL, rather than using REQUEST['fieldname'] directly in
the ZSQLMethod."

The latter would make it a two-tier application which also may be useful
structure for smaller apps where two of the tiers could be collapsed
together.

I would also welcome how/whether this "n-tier" partitioning would also
be useful for thinking  about the internals of Products and ZClasses
when designing them.
In the case of Products and ZClasses all layers may not be present.
e.g. the ZODBC DA is primarily Data API layer only (management interface
not withstanding). 

Comments/debate/flames invited

Nitin Borwankar 
nitin@borwankar.com