I have a class hierarchy that is, for simplicity sake, two levels deep.

User -> MoreSpecificUser

In most cases it will only be necessary for me to retrieve information for
one or the other. I figure if I dont need all the data that the parrent has
to offer why get it.

So here was my solution, I have an interface that all classes must
implement, this exposes Save, Load and Delete.

If I want just the MoreSpecficUser data then I just call its Load() method.
If I want the parent info I call base.Load().

Fine the coupling is low and maintenance is easy.

Here's my only quibble. If I wanted to do this:

public class User: IMyInterface
{
public void Load()
{
//open db connection

//fill dataset

//unpack dataset and fill load object members

//close connection
}
}

public class MoreSpecficUser : User
{
//other interface implementations here

public override void Load()
{
base.Load();

//open db connection

//fill dataset

//unpack dataset and fill load object members

//close connection
}
}

As you acn see I've simply called the base Load method to get all the info
available to this user. However it involves TWO database connections. Now
this make life easy in terms of code maintenance and flexibility in the app
but not sure how comfortable I am about makng two connections to fill and
object.

Re: Getting data in class hierarchy (C#) by Miha

Miha
Mon Jul 26 08:00:15 CDT 2004

Hi Matt,

Acutally you've used only one physicall sql connection :-).
Connection is reused while it is not being active (as in your case).

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
miha at rthand com
www.rthand.com


"MattC" <m@m.com> wrote in message
news:u6mqN1ucEHA.3096@tk2msftngp13.phx.gbl...
> I have a class hierarchy that is, for simplicity sake, two levels deep.
>
> User -> MoreSpecificUser
>
> In most cases it will only be necessary for me to retrieve information for
> one or the other. I figure if I dont need all the data that the parrent
has
> to offer why get it.
>
> So here was my solution, I have an interface that all classes must
> implement, this exposes Save, Load and Delete.
>
> If I want just the MoreSpecficUser data then I just call its Load()
method.
> If I want the parent info I call base.Load().
>
> Fine the coupling is low and maintenance is easy.
>
> Here's my only quibble. If I wanted to do this:
>
> public class User: IMyInterface
> {
> public void Load()
> {
> //open db connection
>
> //fill dataset
>
> //unpack dataset and fill load object members
>
> //close connection
> }
> }
>
> public class MoreSpecficUser : User
> {
> //other interface implementations here
>
> public override void Load()
> {
> base.Load();
>
> //open db connection
>
> //fill dataset
>
> //unpack dataset and fill load object members
>
> //close connection
> }
> }
>
> As you acn see I've simply called the base Load method to get all the info
> available to this user. However it involves TWO database connections. Now
> this make life easy in terms of code maintenance and flexibility in the
app
> but not sure how comfortable I am about makng two connections to fill and
> object.
>
>
>



Re: Getting data in class hierarchy (C#) by Jouni

Jouni
Mon Jul 26 14:30:54 CDT 2004

"MattC" <m@m.com> wrote in news:u6mqN1ucEHA.3096@tk2msftngp13.phx.gbl:

> As you acn see I've simply called the base Load method to get all the
> info available to this user. However it involves TWO database
> connections. Now this make life easy in terms of code maintenance and
> flexibility in the app but not sure how comfortable I am about makng
> two connections to fill and object.

There is no perfect solution. I've used your model with success on a
relatively big system. It performs surprisingly well (especially with SQL
Server) unless you're constructing huge amounts of objects all the time -
and then, you usually have a problem anyway.

If your data structures are reasonably static, you can create base class
code (not constructors, but protected methods of similar functionality -
like your Loads) that initializes the object with the parameters it has
been given. This way you can only make one DB query in the subclass and
pass the base object's data upstream. However, that becomes more painful
once you have more levels and you suddenly decide to change the fields
needed in a base class. It's quite possible to do if all the code is in
one library, though.


If you don't have to deploy your solution into millions of computers
around the world at once, try to use your current approach first. If it
proves too slow, fix it then. That code clarity can prove valuable at
some point, so don't waste it by optimizing prematurely.

--
Jouni Heikniemi, jouni-news@heikniemi.net
http://www.heikniemi.net/hc/ (blog)