Crud Design Question

[John Kraft]

Friends,

I'm working on some crud stuff, and I was looking for opinions on the
subject. Below, I have pasted some VERY simple sample code. Class2
is a "traditiona l" crud type object. In a real example, these objects
would probably implement some kind of ICrud interface with the common
methods.

I'm finding that many times, though, I want to use these objects as
simple data objects, and I don't need all the database functionallity.
I don't want to have to worry about setting connections and such; and
all I hate seeing all the crud methods when I only want to set
properties.

A more common solution would be to have simple data objects that are
passed to a data access class/layer/other-buzzword. However, that
approach can get messy when dealing with tons of objects and an
inexperienced designer (like me).

A thought I came up with was to "blend" the two concepts. Essentially,
leave the data access in the object, but make the methods all static;
like Class1. This has the benefit of allowing me to treat the object
as a simple data object, yet leaving me full data accessibility
without having to instantiate/reference a bunch more classes.

My question is, is there anything fundamentally wrong with the Class1
approach? Is there anything that is going to really bite me in the
rump-roast? It seems to work, and I haven't had a problem with it
yet; but I am very new to design from scratch.
Code is C#, .NET 2.0, VS2005

I should probably also note that I am simply playing around with
design concepts. This isn't for anything "real" right now.

Opinions please.

Thank you,

John

public class Class1
{
private static string connectionStrin g;

private int id;
private string name;

public int Id { get { return id; } set { id = value; } }
public string Name { get { return name; } set { name = value; } }
public static string ConnectionStrin g { get { return
connectionStrin g; } set { connectionStrin g = value; } }

public Class1()
{
// TODO: Add constructor logic here
}

public static void Load(ref Class1 c1, int id)
{
// do stuff here to fill c1 from the database
}

public static void Save(Class1 c1)
{
// do stuff here to save c1 to the database
}

public static void Delete(Class1 c1)
{
// do stuff here to Delete c1 from the database
}
}
public class Class2
{
private string connectionStrin g;

private int id;
private string name;

public int Id { get { return id; } set { id = value; } }
public string Name { get { return name; } set { name = value; } }
public string ConnectionStrin g { get { return connectionStrin g; }
set { connectionStrin g = value; } }

public Class2(string connectionStrin g)
{
//
// TODO: Add constructor logic here
//
this.connection String = connectionStrin g;
}

public void Load(int id)
{
// do stuff here to fill c1 from the database
}

public void Save()
{
// do stuff here to save c1 to the database
}

public void Delete()
{
// do stuff here to Delete c1 from the database
}
}
public partial class Form1 : Form
{
public Form1()
{
InitializeCompo nent();

Class1.Connecti onString = "connection string stuff here";
Class1 c1 = new Class1();
Class1.Load(ref c1, 42);

Class2 c2 = new Class2();
c2.ConnectionSt ring = "connection string stuff here";
c2.Load(42);

}
}

[RobinS]

"Bruce Wood" <br*******@cana da.comwrote in message
news:11******** **************@ n59g2000hsh.goo glegroups.com.. .

Ahh... the troll is back. This time he's had a sex change.

Ignore the troll.

It's the closest to sex he's had in a long time.

[John Kraft]

On Wed, 21 Mar 2007 09:03:02 +0100, "Christof Nordiek" <[e-mail] >
wrote:

>Hi John,

some ideas:

>The Id should be managed by the business-layre (or below). So atleast the
setter of the Id should be private.

>HTH
Christof

Christof,

Here's a quick question. If the Id is private, how would the business
layer access it? Private means it can only be accessed by itself.
Usually, the methods discussed previously rely on another class to
load the actual objects. If so, they will not have access to a
private member.

John

[Jon Skeet [C# MVP]]

John Kraft <jh*****@barbec ueguy.comwrote:

Here's a quick question. If the Id is private, how would the business
layer access it? Private means it can only be accessed by itself.
Usually, the methods discussed previously rely on another class to
load the actual objects. If so, they will not have access to a
private member.

Christof was only suggesting that the *setter* should be private. It
only needs to be used by the Load method. After the Id is set, there
should be no need to change it. Personally, I'd make it a readonly
property backed by a readonly variable, set in the private constructor
called by the Load method.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[John Kraft]

On Sat, 24 Mar 2007 11:25:10 -0000, Jon Skeet [C# MVP]
<sk***@pobox.co mwrote:

>John Kraft <jh*****@barbec ueguy.comwrote:

>Here's a quick question. If the Id is private, how would the business
layer access it? Private means it can only be accessed by itself.
Usually, the methods discussed previously rely on another class to
load the actual objects. If so, they will not have access to a
private member.

Christof was only suggesting that the *setter* should be private. It
only needs to be used by the Load method. After the Id is set, there
should be no need to change it. Personally, I'd make it a readonly
property backed by a readonly variable, set in the private constructor
called by the Load method.

Jon,

Thanks. I misunderstood what he was getting at. That makes good
sense. I appreciate your comments.

John