DAL as Base Class - any Merits to Doing So?

[Jeremy S.]

I have started with a new client that is having me substantially modify an
existing .NET application. I have found that the original developer
implemented a lot of data access layer (DAL)-type functions in a base class.
Now I am refactoring. As I'm doing so, I realized that I *never* would have
thought to make a DAL class a base class for other UI-related classes or for
business objects. In my way of thinking I would always have the DAL class be
consumed via containment/delegation by business objects or even UI classes
on occasion.

Question: Would any of you ever recommend having a proper DAL class be
inherited by business object or UI-related classes? I understand that it can
work. But I only see disadvantages (e.g., with single inheritance you lose
that one opportunity...). I understand there isn't necessarily a right vs
wrong answer here... just looking for some thoughtful feedback on the
subject.

Thanks.

 

[Arne Vajhøj]

I have started with a new client that is having me substantially modify an
existing .NET application. I have found that the original developer
implemented a lot of data access layer (DAL)-type functions in a base class.
Now I am refactoring. As I'm doing so, I realized that I *never* would have
thought to make a DAL class a base class for other UI-related classes or for
business objects. In my way of thinking I would always have the DAL class be
consumed via containment/delegation by business objects or even UI classes
on occasion.

Question: Would any of you ever recommend having a proper DAL class be
inherited by business object or UI-related classes?

No. It effectively make the app a single layer app.

Arne

 

[sloan]

G'aaccckkk.

No way.

 

[Cowboy \(Gregory A. Beamer\)]

DAL class as a base class for more distinct DAL implementation (ie, use
generics at base and then inherit)? Maybe. But most likely you would use the
"inheritance" chain through interfaces instead. Still a possibility,
however.

DAL as a base class for UI or business? Not a good idea.

The way you describe things, you are tightly coupling UI to business or data
layers. I cannot think of a sane reason to do that. But I also find it hard
to use the Active Record pattern, as it mixes behavior with state, so I may
be a bit more extreme in my adherence to SOLID than some. I still cannot
think of one good reason to have data access in a base class for a UI class.

Peace and Grace,

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

********************************************************
| Think outside the box! |
********************************************************