Re: OO Design, Physical Implementation, DAOs

From: oj (oaguayo75_at_yahoo.com)
Date: 10/21/04 

Date: 21 Oct 2004 11:59:09 -0700

"Phlip" <phlip_cpp@yahoo.com> wrote in message news:<gixdd.11230$Rf1.9047@newssvr19.news.prodigy.com>...
> 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?

 Maintainability is the major factor influencing the need to create a
business object layer. Also, my boss would like to eventually
integrate some third party business rule and business process tools
into the mix. I looked at a couple of business rule tools and both
expected an OO structured program to exchange messages via the
business object instances.
>
> > 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.

I'm sure that the methods you suggest would work wonders for me if I
fully understood everything that you mentioned in your post. We do
have an existing application that I have maintained, but our new
project is not an extension to this application but rather should
result in a new stand alone application as well. I basically am
starting from scratch with class diagramming, use case and sequence
diagram construction to try and create a blueprint for my C# code. I
don't have any existing web pages for this new project constructed.

Relevant Pages

  • Re: Newbie object design questions
    ... A good profitable business needs to adapt to a changing ... And before you jump on that, I am saying that these "features" ... rather it leverages frameworks. ... IMHO it undermines the true usefulness of oo design. ...
    (microsoft.public.dotnet.languages.csharp)
  • 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. ... Refactor to merge these aspects ...
    (comp.object)
  • Object design questions
    ... This layout was obtained from some design docs in our Rational Unified ... Application layer via some MVC framework. ... The application layer interacts with the business layer to get data and ... Http handler class (the controller in MVC) calls our application ...
    (comp.object)
  • Re: Front End or Backend - Where to put what?
    ... Unless you are using SQL Server, DB2 or Oracle you can forget your three ... If you are using Jet then _just_ get the design of the database right (and ... depending on the business and the way that business handles the data. ... > on my part is the tiered approach of 'Data Layer, ...
    (microsoft.public.access.tablesdbdesign)
  • Re: app design/architecture question
    ... Layer/DataLayer classes. ... It really should not be a developer's decision since it is a design ... If the UI and business layers are dealing with objects of type Part ... The purist in me doesn't want the business layer to know about generic ...
    (microsoft.public.dotnet.framework.aspnet)