Re: OO Design, Physical Implementation, DAOs

From: Phlip (phlip_cpp_at_yahoo.com)
Date: 10/20/04 

Date: Wed, 20 Oct 2004 17:31:56 GMT

oj wrote:

> I'm just starting to wrap my mind around application programming from
> the OO perspective. I've been asked to attempt to design and implement
> a small web application based on OO prinicipal. All previous
> development was completed by a third party group of programmers who
> chose to not include a business object layer into the development
> process.

Oooh, a challenge. How to architect such a layer?

The best answer, before reading more, is to implement the _minimum_ that is
directly useful to your exact set of requirements.

(The worst answer, to provide perspective, is to look up a DAO layer in a
book and implement the entire thing. Don't design in the abstract; always
design with feedback from live code, and feedback from reviews of that
code's features.)

> I recently purchased a couple of books to help get me started:
> Beginning C# Objects by Barker and C# adapted version of the GoF
> Design Patterns book. I have to admit with little to no background in
> OO design I attempted to read the Design Patterns book and realized it
> was a tad over my head. I decided to get my feet wet with Barker's
> book and have learned enough over the past few weeks to get a decent
> handle on how to determine and model my domain class objects,
> attributes, and behaviors.

Good. While you do that, also spend time adding the highest-priority
features to your Web page. Get frequent customer review for them, and write
_copious_ unit tests for them. There may be a C# version of HttpUnit. Use
HttpUnit if you know Java, and also write unit tests for all the code that
supports the Web pages.

I'm saying this because those books don't say it, and because the unit tests
and frequent reviews are more important for success than a data objects
layer.

> Currently, the presentation layer(aspx pages), within our existing
> application, talks directly to the DAL(made of DataAccess component
> and DataSet classes) via the C# code behind pages for each. Over the
> past year I've been maintaining this structure. Now on entirely new
> project I'm being asked to design and implement an additional layer in
> addition to the presentation and DAL layers, and I'm having trouble
> understanding how to connect them. Oh yea, did I mention I'm working
> on my own as my non-profit employer can only afford one programmer at
> this time. Fun! Fun!

Who is asking you to design a layer? What is the real business value you
intend to provide?

> I have a many questions regarding the problem I've been given but here
> are just a few:
>
> 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?

Construct it by writing a few of the real features you need, under test, and
then learn what aspects they have in common. Refactor to merge these aspects
into the beginning of a DAL. Don't add every DAL feature you can think of -
you are not selling a DAL.

Refactor so those few Website features call the DAL, using a clean and
simple interface. Then add a new Website feature. The odds are high it will
be able to re-use the DAL as is. Otherwise, write the data access code anew,
to get the Website feature working. When it passes tests, refactor to
migrate those features into the DAL, and integrate them with what's there.

Run all your tests after <10 edits.

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

Implement the simplest interface that those Website features need. They will
tell you what they need. For us to decree one or the other pattern, when we
can't see your source code, would add incredible risk.

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

Read the book /Refactoring/, and look at the pattern "Duplicate Observed
Data". (It's a pattern, not a refactor, but of course it showed up in the
Refactoring book because that's what the author was writing when he thought
of it;)

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

This is called "vendor-lockin". This early in the game, don't fight it.
Re-using a vendor's tools is good, because it's re-use. Long term, layers of
your program should emerge that are untainted by these DataSet objects. If
you don't need to pass one into a servant function, then only pass its
values. The encapsulation starts there.

> Sorry about the longwinded post, but I need someone to check my
> understanding before I go any further.

Your understanding of OO is limited. If it were advanced (even far beyond
mine), you should _still_ design by adding features first. The sooner you
have tests and features, the sooner you deliver the features and reap the
rewards of their business value. Only then do you "design", essentially to
get ready for the next feature requests. 

-- 
  Phlip
  http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces

Relevant Pages

  • Re: OO Design, Physical Implementation, DAOs
    ... I've been asked to attempt to design and implement ... How to architect such a layer? ... > features to your Web page. ... What is the real business value you ...
    (comp.object)
  • Re: OOP/OOD Philosophy
    ... The methodology is well-documented. ... It is agile because the term 'extreme' as been so over-exposed that the ... > in which you do design can enable the team to respond to change, ... > that surveys of users have shown that nearly 50% of all features in a BDUF ...
    (comp.object)
  • =?windows-1252?Q?www=2Eelectronics=2Dmac=2Dsony=2Ecom___Motorola_KRZR_K1_Phon?= =?windows-12
    ... Product Features and Technical Details ... the KRZR K1 is the definitive handset for those who ... design, you get Bluetooth wireless technology, an integrated music ... detailing and premium materials shrouded within a distinctive metallic ...
    (alt.cellular.verizon)
  • Re: Code generation - Was: AOP in PHP - Was: OO in PHP
    ... It's called meta programming and though the concepts ... else (or there is no performance problem at all), ... There is much design humbug with respect to C++ and Java ... More features usually means more code. ...
    (comp.lang.php)
  • Re: OOP/OOD Philosophy
    ... in which you do design can enable the team to respond to change, ... Even Scrum, which is my area of practice, requires training for all members. ... We delivered the functionality that the customer desired, ... that surveys of users have shown that nearly 50% of all features in a BDUF ...
    (comp.object)