Let me add some context here: <tataryn:craig/> :-)
And some more:
In our VB/COM app, our business layer never really knew where data was
comming from. And I'm not just talking about what "database" the data was
coming from, I mean it didn't even know if the data was coming back from a
flat file, a queue or a database. We achieved this by only returning the
serialized data of the object which were reinflated into our business
objects upon retrieval, so it looked something like this. And we made a
little routing manager that figured out what DataObject should be
instantiated for a business object.
Here is the definition for let's say the clsEmployee business object's
retrieve function:
Public Sub Retrieve(EmpID as String)
Dim da as IDataObject
Dim rm as RoutingManager
Dim colFields as Collection
Dim colFilters as Collection
Dim vPropBag as Variant
'Ask the routing manager what data object to instantiate
Set rm = new RoutingManager
'this looks up in a map what the CLSID of the data object
'associated with the business object clsEmployee is, it then
'instantiates this object and passes it back. So, if sometime down
'the road we need to retrieve employees from an XML file, we would
'simply update the map that the routing manager feeds off of for the
'bEmployee.clsEmployee entry and point it to the new Dataobject.
Set da = rm.getDataObject("bEmployee.clsEmployee");
'
'build both the fields collection (i.e. the fields you want returned)
'and the filters collection. For this example we want to
'add empid = value to the filters collection, we never actually added
'sql stuff in the business layer, we just added tokens which were
'transformed into SQL (maybe) in the datalayer from the contents of
'the fields and filters collection
'.....
'now ask the datalayer object to get us the object from the database
vPropBag = da.retrieve(colFields, colFilters)
'grab the non datasource centric property bag and have this object
'inflate itself with it
Me.Deserialize(vPropBag)
'we had to do all this messy serialization/deserialization because
'sending objects accross process or physical boundaries was not as
'straight forward in COM as it is in Java. The vPropBag would most
'likely just be a buch of field=value strings, something COM serializes
'natively.
End Sub
So, barring all that, I could reuse this architecture above, coding a data
object for each business object and having it grab data by whatever means
necessary, and because it is so abstracted, I could write a dataobject to
use the native API of a connection pool and never have to rewrite a Business
object if the new Datastore were to change to an XML file (probably does not
need a JDBC connection ;).
Where I was getting lost was, how do I get a connection from the connection
pool all the way down to the bottom level Data layer object? I think I have
the answer in that I could just have a kind of central static class that is
initialized with the Struts Datasource on web app startup, and the Datalayer
objects that need to get a connection to a database in order to manipulate
data, could simply ask for it via the static methods of this class.
Memories....
Thanks!
<tataryn:craig/>
P.S. I am without static IP, and thus computer-programmer.org tutorials are
down. I should be getting a static IP in about a week! Hopefully by then I
will have played around with 1.1 long enough to revise my tutorial!
>From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>To: Struts Users Mailing List <[EMAIL PROTECTED]>
>Subject: Re: Alternative Datsource Hot-potatoing...
>Date: Fri, 6 Sep 2002 19:32:17 -0700 (PDT)
>
>
>
>On Fri, 6 Sep 2002, Craig Tataryn wrote:
>
> > Date: Fri, 06 Sep 2002 17:57:42 -0500
> > From: Craig Tataryn <[EMAIL PROTECTED]>
> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: Re: Alternative Datsource Hot-potatoing...
> >
> > Thanks Ted, I'll check it out. But just out of curiosity, why would you
> > ever want your Business Layer to know about Datasources?
> >
> > Craig.
>
>This "Craig" stuff is going to get confusing :-).
>
>The strategic issue, IMHO, is that you want business layer classes to know
>the absolute minimum information possible to achieve its objectives. In
>the particular case at hand, the minimum possible knowledge would be
>what java.sql.Connection to use for their JDBC activities. If you're in a
>batch-mode single threaded application, why would you want to go to all
>the effort to establish a DataSource object, when you'd only ever use a
>single Connection from it? If you're going to pass in a reference to a
>JDBC-something object, it seems better to me that you pass a Connection
>instead -- that way a batch app can pass the one-and-only Connection it
>creates, and the business logic layer is none the wiser.
>
>Craig (McClanahan :-)
>
>
>
>--
>To unsubscribe, e-mail:
><mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail:
><mailto:[EMAIL PROTECTED]>
Craig W. Tataryn
Programmer/Analyst
Compuware
_________________________________________________________________
Join the world�s largest e-mail service with MSN Hotmail.
http://www.hotmail.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
