Re: OO Design, Physical Implementation, DAOs
From: Otavio C. Decio (REMOVEMEodecio_at_earthlink.net)
Date: 10/20/04
- Next message: Otavio C. Decio: "Re: OO Design, Physical Implementation, DAOs"
- Previous message: Phlip: "Re: OO Design, Physical Implementation, DAOs"
- In reply to: oj: "OO Design, Physical Implementation, DAOs"
- Next in thread: Otavio C. Decio: "Re: OO Design, Physical Implementation, DAOs"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 20 Oct 2004 13:39:10 -0400
Hi,
> 1. On a high level is creating data access component classes made up
> of DataAdapter objects, Command objects, and sql statements which are
> mapped to datasets and talk directly to my SQL Server 2000 database
> the proper way to constuct a DAL? If not where can I find
> instruction/examples on the proper way to construct the DAL?
>
In my projects I created a set of Data Access Objects and the DAL served as
a factory of them (when SELECTing) and a persistence mechanism when
inserting, updating and deleting. The Data Objects pretty much map to
tables, and I have other constructs to implement JOINs. The big advantage
(OO or not) is that I can change the DAL so (for example) it gets data from
different data sources - in .NET is very easy to get locked into a
particular database if you're not careful.
> 2. What is the role of data access objects in OO design? Are these
> purely DAL components? Or if I have a domain class which potentially
> has a collection of records as an attribute is it alright to create
> this collection as a DataTable or an array of DataRows?
>
Data Access Objects are in a way an annoyance. They exist because of a
technological limitation: once you turn the computer off, data is gone. And
currently most of the persistence mechanisms are relational databases, so
Relational-OO mapping will happen one way or the other. I'd rather have an
object model that is useful for the application and that can be produced and
consumed by the DAL. BTW, I don't try to support OO concepts when it comes
to persisting data.
> 3. I'm probably completely off on #2, where can I find
> instruction/examples on the physical implementaion of OO model? I'm
> not understanding how I'm going to physically get data out of the DAL
> into my objects and then get that data out of my objects and presented
> to the GUI.
>
Martin Fowler's "Patterns of Enterprise Application Architecture" is a good
start, IMHO.
> 4. Currently, DataSet objects are instantiated in the aspx code behind
> pages and datatables, within the dataSet, are bound to controls like
> datagrids and datalists which works very nicely. How is this done when
> working with objects and collections of objects?
If you're careful about naming conventions you can use the ArrayLists of
data access objects produced by the DAL to directly bind to datagrids.
>
> Sorry about the longwinded post, but I need someone to check my
> understanding before I go any further.
>
> Any information is appreciated.
>
> oj
HTH
Otavio
- Next message: Otavio C. Decio: "Re: OO Design, Physical Implementation, DAOs"
- Previous message: Phlip: "Re: OO Design, Physical Implementation, DAOs"
- In reply to: oj: "OO Design, Physical Implementation, DAOs"
- Next in thread: Otavio C. Decio: "Re: OO Design, Physical Implementation, DAOs"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
