Design Questions 
Author Message
 Design Questions

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.*-*-*.com/ ; 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?

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?

Does the concept of separation outweigh the creation of a data access
component for every biz function call?

3.  Modeling the data access component classes after the tables.  could
someone elaborate on this one?

4.  Building for ASP, VB, or both?
    What is the best wat to gear functions ByRef/ByVal  and Function Returns
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 they
also have to be variants for asp?

It seems like the more and more I try to do things the "right way", the more
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.

Thanks,
-=Chris



Mon, 14 Jan 2002 03:00:00 GMT  
 Design Questions
Can't resist a chance to voice an OPINION...

(Answers are inline)

Quote:

>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?

Its faster no doubt, but I'm with you on this one.  DBAs change passwords
and applications move all the time...  I get my  connection string
information from registry entries I retrieve in the components Initialize
event...  I don't care for DSNs and I'm not going to recomplie when I move
from the dev environment to production because they're on separte machines
with different account info...

I vote for DSN-Less connections with dynamic information from where ever you
want to store and retrieve it...

Quote:

>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?

>Does the concept of separation outweigh the creation of a data access
>component for every biz function call?

Size & Budget issue for me...  How big is the app (users and transaction
volume) and how big is the budget.  I'm happy to split the logic, but It
means more code to manage and more complexity...  Definitly more scalable,
the question is do you need it to now and/or will you ever need it to be
able to handle amazon.com's order entry system...

Quote:

>3.  Modeling the data access component classes after the tables.  could
>someone elaborate on this one?

I love this approach...  Gone so far as to write a code generator that walks
the table and sets up all the properties for each field and creates methods
for (SetProps, Load, Save and Delete)... Also creates a collection class to
hold multiple objects. Once you start treating everything like an object its
hard to stop.   Makes the GUI designers job easier if you can rid him/her of
worring about ADO.  Always have a generic Data object around that I can pass
a SQL statement to and get a quick recordset if i need something special.

Quote:

>4.  Building for ASP, VB, or both?
>    What is the best wat to gear functions ByRef/ByVal  and Function
Returns
>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 they
>also have to be variants for asp?

Most of the time I'm dealing with form data from ASP.  Not complicated
stuff... I pass data ByVal and I always return a Long from a function... I
try to keep my references to ASP limited to the objects themselves.  I'm
also a big fan a passing the built-in ASP objects to VB in the OnStart
Event...

Quote:

>It seems like the more and more I try to do things the "right way", the
more
>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.

Your right on the money... There is not ONE way to do this!
Quote:
>Thanks,
>-=Chris



Tue, 15 Jan 2002 03:00:00 GMT  
 Design Questions
OK, to further the plot...how would you do it and what do you think the
pros/cons are for persisting the connection info...

1)  INI FIle
2)  Registry
3)  VB6 Class Proprty Persistance

Personally, I'm fond of INI files...but Registry would be faster...
I'm not sure where/how Class Persistance in VB6 Saves the data...

Quote:
> Its faster no doubt, but I'm with you on this one.  DBAs change passwords
> and applications move all the time...  I get my  connection string
> information from registry entries I retrieve in the components Initialize
> event...  I don't care for DSNs and I'm not going to recomplie when I move
> from the dev environment to production because they're on separte machines
> with different account info...

> I vote for DSN-Less connections with dynamic information from where ever
you
> want to store and retrieve it...



Tue, 15 Jan 2002 03:00:00 GMT  
 Design Questions
Hi Christopher:



Quote:
> 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?

The obvius one: this way, using stateless objects, establish connection is
faster (no need to look each time at the registry, for example), and it
might be OK if developping an on-demmand app (you will know the servers
names in advance, and -if you're releasing your sourcecode to your client-
if servers change, they can change the names in code and rebuild...  A
sugestion (whick I can't still make work).  Since data layer should always
be running on the same machine the database is, you should try hardcoding a
connection to 'localserver', 'loopback' or whatever.  As I say, there migth
be a way to achive this, but I still didn't find it  (so if someone knows a
way...)

Quote:

> 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?

No, it isn't, although in any case, you should logically separate your data
access classes in order to better maintenance.  For instance, I'm now
developping such a three-tier monster which was intended to only access to
just one SQL 7 server, but now, the app has being reescaled to have
automation processes to Word to make automatical reports.  Since we have
data access classes from the very beginig, this way will only affect having
new methods whitin data classes without moving biz code nor any other major
difficulties or incompatible code...

Quote:
> Does the concept of separation outweigh the creation of a data access
> component for every biz function call?

Not too much if using MTS...

Quote:

> 3.  Modeling the data access component classes after the tables.  could
> someone elaborate on this one?

I would say it deppends on your app model (specially its volume).  Not an
easy answer.

Quote:

> It seems like the more and more I try to do things the "right way", the
more
> 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.

He, heee.  So, welcome :D
--
SALUD,
Jess
*******

*******


Tue, 15 Jan 2002 03:00:00 GMT  
 Design Questions

1. Modeling the data access component classes after the tables
Assuming you are using a relational database I think this is only a good
solution if your data access is quite simple. As soon as you need to access
or update data from many tables, performance is much better if you send one
complex SQL statement to the server (or use a stored procedure). If have
just recently seen a large project fail because of going OO overboard in
here. Another point to consider is that it can be quite tricky to prevent
memory leaks by introducing circular references in collections - this is not
as easy as one might think first.

2. Connection String
We use an MTS shared property to store the connect string information.
Because our packages are set to "leave running when idle" the registry is
read only at package startup.

To make configuration as easy as possible we use Microsoft data link files
(*.udl). You can create one by choosing "New, Microsoft Data Link" in
windows explorer. We store the path to the .udl file in registry.

The connection string is extracted fromt the.udl file with the following
function:

Private Function ConnectStringGet() As String
'Get Connect String from UDL File

    Dim strUDLPath As String
    Dim strConnectString As String
    Dim obj As New MSDASC.MSDAINITIALIZE
    Dim StrLen As Long

    'Get udl filename from registry
    strUDLPath = GetSetting("Medam", "Database", "UDLFile")

    If Len(strUDLPath & "") > 0 Then
        'Extract connect string from udl file
        Call obj.LoadStringFromStorage(strUDLPath, strConnectString)
    Else
        Err.Raise mdlUDLPathNotFound, "Cant find UDLPath-Entry in registry"
    End If

    'If you dont do this VB will crash
    StrLen = InStr(strConnectString, Chr(0)) - 1
    ConnectStringGet = Left(strConnectString, StrLen)
End Function



Quote:
> 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?

> 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?

> Does the concept of separation outweigh the creation of a data access
> component for every biz function call?

> 3.  Modeling the data access component classes after the tables.  could
> someone elaborate on this one?

> 4.  Building for ASP, VB, or both?
>     What is the best wat to gear functions ByRef/ByVal  and Function
Returns
> 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
they
> also have to be variants for asp?

> It seems like the more and more I try to do things the "right way", the
more
> 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.

> Thanks,
> -=Chris



Tue, 15 Jan 2002 03:00:00 GMT  
 Design Questions
The question which gates my response again falls on scale...

Are we building the next Amazon?

    I'd go with Peter's suggestion of MTS Shared Properties

Maybe not all that critical and not heavily used...

    Definitely registry...

 - Paul

Quote:

>OK, to further the plot...how would you do it and what do you think the
>pros/cons are for persisting the connection info...

>1)  INI FIle
>2)  Registry
>3)  VB6 Class Proprty Persistance

>Personally, I'm fond of INI files...but Registry would be faster...
>I'm not sure where/how Class Persistance in VB6 Saves the data...

>> Its faster no doubt, but I'm with you on this one.  DBAs change passwords
>> and applications move all the time...  I get my  connection string
>> information from registry entries I retrieve in the components Initialize
>> event...  I don't care for DSNs and I'm not going to recomplie when I
move
>> from the dev environment to production because they're on separte
machines
>> with different account info...

>> I vote for DSN-Less connections with dynamic information from where ever
>you
>> want to store and retrieve it...



Wed, 16 Jan 2002 03:00:00 GMT  
 Design Questions
Hi Chris

probably stating the obvious but  I would store the information in a
AppSettings object.

Then the implementation could change, and missing settings can be managed
and other such good things.

At the moment Registry then .INI have my vote, depending on requirements.
Oh and how about an XML file?

Jason

(remove not to mail me)



Quote:
> OK, to further the plot...how would you do it and what do you think the
> pros/cons are for persisting the connection info...

> 1)  INI FIle
> 2)  Registry
> 3)  VB6 Class Proprty Persistance

> Personally, I'm fond of INI files...but Registry would be faster...
> I'm not sure where/how Class Persistance in VB6 Saves the data...

> > Its faster no doubt, but I'm with you on this one.  DBAs change
passwords
> > and applications move all the time...  I get my  connection string
> > information from registry entries I retrieve in the components
Initialize
> > event...  I don't care for DSNs and I'm not going to recomplie when I
move
> > from the dev environment to production because they're on separte
machines
> > with different account info...

> > I vote for DSN-Less connections with dynamic information from where ever
> you
> > want to store and retrieve it...



Fri, 18 Jan 2002 03:00:00 GMT  
 Design Questions



Quote:
> 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.

Quote:
> 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.

Quote:
> 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
UDT's).

Quote:
> 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.

Quote:
> 4.  Building for ASP, VB, or both?
>     What is the best wat to gear functions ByRef/ByVal  and Function
Returns
> 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
they
> also have to be variants for asp?

I think you're right about ByRef arguments and ASP. Function returns are by
definition ByVal.

Quote:
> It seems like the more and more I try to do things the "right way", the
more
> 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.

Jeff Kohn
Orca Technologies
jkohn "at" orca "dot" net



Fri, 18 Jan 2002 03:00:00 GMT  
 Design Questions
Hi Christopher,

I think using registry is best as registry is already synchronized and
indexed.  Sync. access may not be an issue if your access is read-only
(however, you never know if it will be this way forever), indexing is not an
issue if the file is small (you cannot be certain that it will not grow).
In any case, I do not see disadvantages to using the registry vs. an ini
file.

Alex.



Quote:
> OK, to further the plot...how would you do it and what do you think the
> pros/cons are for persisting the connection info...

> 1)  INI FIle
> 2)  Registry
> 3)  VB6 Class Proprty Persistance



Fri, 18 Jan 2002 03:00:00 GMT  
 Design Questions
Question:

My app must work with either SQL Server or Oracle.  Given this, when
modeling my data access components, how much (if at all)  should I rely on
stored procedures?

Quote:

>1. Modeling the data access component classes after the tables
>Assuming you are using a relational database I think this is only a good
>solution if your data access is quite simple. As soon as you need to access
>or update data from many tables, performance is much better if you send one
>complex SQL statement to the server (or use a stored procedure). If have
>just recently seen a large project fail because of going OO overboard in
>here. Another point to consider is that it can be quite tricky to prevent
>memory leaks by introducing circular references in collections - this is
not
>as easy as one might think first.



Fri, 18 Jan 2002 03:00:00 GMT  
 Design Questions
What about the use of business objects in ASP pages?  I struggle to
return a recordset from the business tier.  Doesn't seem to work.  Does
it have to be a VARIANT or IDispatch*?

Let's say I want to browse, update, edit, batch-update a datebase.  I
have a data access tier, business tier and the ASP user tier.  Is it
appropriate to pass the recordset back to the ASP page or just to the
business tier and create a type of array which returns the data? Client
should be as thin as possible.

Thanks.

Bob



Quote:
> 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?

> 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?

> Does the concept of separation outweigh the creation of a data access
> component for every biz function call?

> 3.  Modeling the data access component classes after the tables.
could
> someone elaborate on this one?

> 4.  Building for ASP, VB, or both?
>     What is the best wat to gear functions ByRef/ByVal  and Function
Returns
> 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 they
> also have to be variants for asp?

> It seems like the more and more I try to do things the "right way",
the more
> 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.

> Thanks,
> -=Chris

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.


Sat, 19 Jan 2002 03:00:00 GMT  
 Design Questions


Quote:
> What about the use of business objects in ASP pages?  I struggle to
> return a recordset from the business tier.  Doesn't seem to work.  Does
> it have to be a VARIANT or IDispatch*?

I think it should be a VARIANT containing an IDispatch*


Sat, 19 Jan 2002 03:00:00 GMT  
 Design Questions
ASP code is generally regarded as middle-tier code. In your ASP code, you
might dim objects from your compiled middle-tier components (e.g., running
in MTS) that fetch data and enforce business rules. These objects can return
a recordset to the ASP code. The ASP code can then format HTML to return the
data back to the client.
Quote:

>What about the use of business objects in ASP pages?  I struggle to
>return a recordset from the business tier.  Doesn't seem to work.  Does
>it have to be a VARIANT or IDispatch*?

>Let's say I want to browse, update, edit, batch-update a datebase.  I
>have a data access tier, business tier and the ASP user tier.  Is it
>appropriate to pass the recordset back to the ASP page or just to the
>business tier and create a type of array which returns the data? Client
>should be as thin as possible.



Sat, 26 Jan 2002 03:00:00 GMT  
 
 [ 13 post ] 

 Relevant Pages 

1. App Design Questions

2. General Design Question- Advice sought.

3. Word/Access Design Question

4. Application design question

5. Design questions - VB.NET

6. UI design question

7. UI design question

8. Real simple design question

9. Design Question:

10. Interface Design Question

11. Designing Question

12. Class Design question

 

 
Powered by phpBB® Forum Software