Re: Best Practices for DataAccess Layer in VB6
- From: jamesfreddyc <jamesfreddyc@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 16 Nov 2007 08:20:00 -0800
"Ralph" wrote:
There are two ways to approach these kinds of design decisions. One from a
business case point of view, the other from an OO point of view. All lead to
the same result. But one thing will become quickly apparent - no one model
will be 'best' for all occasions.
While often considered an 'advanced' topic. I feel a general understanding
of the impedence mismatch between OO and Relational technologies in the
beginning make the why's and how's of suggested strategies easier to
swallow.
http://www.agiledata.org/essays/impedanceMismatch.html
Put simply - the architecture and building blocks (often erroneously
referred to as 'objects') of a data store seldom relates directly to the
business needs or objects in a well structured application.
Building an object based on a specific query is a step in the right
direction from, say, simply creating an object based on each table. But even
then can be rather wasteful - since what is a Recordset but an object that
contains a collection of objects?
I see a lot of reading in your future. <g>
-ralph
Great info and yes, lots of reading in my future <g>
Wading through the info, I found a couple of items of interest that do apply
specifically to my situation -- yet I am still unable to grasp ahold of a
specific answer...
RE: Data Access Objects: "The typical approach is for there to be one data
access object for each business object, for example the Customer class would
have a Customer_Data class."
This seems to be my current situation. But not much in the way of a
conclusion to whether or not to keep this approach or evolve it into
something else. Perhaps some clarificaiton about my situation could spark
further discussion?
1. This is not a standalong VB applicaiton. It's part middleware, part
customization of a standard app (ESRI's ArcGIS), part non-spatial RDBMS
integration with spatially-enabled RDBMS.
2. In the simplest terms, I am strictly reorganizing existing objects (what
ArcGIS is made up of) into a collection that makes sense for a specific user.
That is, ArcGIS is complex to most non-GIS users -- I dumb it down by
organizing these existing ArcObjects.
3. I am creating transperancy between an existing (3rd party) non-spatial
RDBMS with GIS spatial databases -- and I am able to do this because most
non-spatial databases ARE spatial (if address info is being maintained, then
it IS spatial data).
Just think of ArcGIS (map software) as the Front-End UI. In order to get
that non-spatial data into the map UI, I am using StoredProcs server side
that receive parameters from that map UI (customized UserForms and other
controls), then build ADOrs client-side. What's important here is that these
are strictly SELECTS, the rest of the processing is done client-side
(unleashing the power of the Spatial Analsyis), which ultimately I am tapping
into both disciplines: more traditional server-side db processing with some
computations, then additional spatial analysis client-side produces an
extremely powerful application.
Anyway, the "Class Normalization" topic was next on my list, and seemed most
relevent after a quick review. But again, from the info found, I don't see
the disadvantages in my current setup (Class mod's are mapped to StoredProcs).
What say you?
BTW -- great info. I'll be spending quite a bit of time at the Agile site.
Take Care,
j
.
- Follow-Ups:
- Re: Best Practices for DataAccess Layer in VB6
- From: Stephen Howe
- Re: Best Practices for DataAccess Layer in VB6
- References:
- Re: Best Practices for DataAccess Layer in VB6
- From: Ralph
- Re: Best Practices for DataAccess Layer in VB6
- Prev by Date: Re: Error => -2147467259 Could not save; currently locked by ano
- Next by Date: Re: Fill typed dataset with one stored procedure call
- Previous by thread: Re: Best Practices for DataAccess Layer in VB6
- Next by thread: Re: Best Practices for DataAccess Layer in VB6
- Index(es):
Relevant Pages
|
|