> OK, I'm sure some of these questions have been asked before, but after
> viewing some of the tech-ed slides, I seem to be in a design quandry.
> http://www.teched99.com/slides/9-406.ppt for starters.
> 1. The first thing I noticed on a n-tier slide under tips was "Hard Code
> the Connection String in the Data Access Tier"
> I come from the school of hard-coding-is-evil
> What is everyone's experience with this approach?
I think hard-coding is always a bad idea; some things just aren't worth the
performance gain you might (or might not) get. I would recommend using a
shared property now, and IMDB in Win2k. That way you only have to read it
from the registry once.
> 2. Next is the question of Data Access and Biz Logic tiers vs. just a
> BizData tiers combined...
> Let's say you are gearing an n-tier solution towards just MSDE/SQL7...is a
> separate data access tier necessary?
It depends on how big your application is, and how efficient you need your
data access to be. Separating into two tiers can actually boost performance.
You are able to provide a rich interface with properties, methods, and
events for the client programmer. At the same time the interface between the
business tier and the data tier can be made very efficient using stateless
MTS components. I think putting the business tier in MTS and making the
client programmer use stateless components is less desirables, unless your
only client is going to be ASP pages. Stateless programming is
non-intuitive, and requires more work on the client's part since they are
going to have to manage state locally.
> Does the concept of separation outweigh the creation of a data access
> component for every biz function call?
I think so. You don't necessarily need a components for every business
function; my approach is to have a data component for every business object.
For a good overview of this stuff, see Rockford Lhotka's book 'VB6 Business
Objects' by Wrox Press. The only thing I disagree with him about is using
LSET and string buffers to pass data between the biz and data tier (I prefer
> 3. Modeling the data access component classes after the tables. could
> someone elaborate on this one?
This could be a good approach if you need to use existing data. If you're
starting a new project, this seems backwards to me. I would design the
business classes first, and determine the table structure based on the needs
of the components.
> 4. Building for ASP, VB, or both?
> What is the best wat to gear functions ByRef/ByVal and Function
> for both VB and ASP use since ASP is stuck with everything as Variants?
> ByVals can be typecast while ByRefs have to be Variants for asp right?
> What about the function return values?...can the be typecast or do
> also have to be variants for asp?
I think you're right about ByRef arguments and ASP. Function returns are by
> It seems like the more and more I try to do things the "right way", the
> and more variations I see and the more confused I get.
> I realize that there are more than just one "right" way to do things.
This is relatively new territory, and there is no single right way to do
things. In fact, many of the 'experts' will give quite different advice
about how things should be done.
jkohn "at" orca "dot" net