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);

}
}

[sloan]

You should not mix the object's code, with the code that creates the
objects.

Instead, you push that code into a Manager or Controller class.

Ex

Employee (object)
EmployeeControl ler

you should not marry the db of choice to your code, this is why people
seperate the "BusinessLo gic" layer and the DataAccess layer.

See

http://sholliday.spaces.live.com/blog/
6/5/2006
Custom Objects and Tiered Development II // 2.0

"John Kraft" <jh*****@barbec ueguy.comwrote in message
news:06******** *************** *********@4ax.c om...

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);

}
}

[Susie DBA [MSFT]]

Sloan

I don't agree with that.

Maybe you need to learn how to write SQL Server

there is only one database that matters; and it has been this way for
10 years



On Mar 20, 4:33 pm, "sloan" <[e-mail] wrote:

You should not mix the object's code, with the code that creates the
objects.

Instead, you push that code into a Manager or Controller class.

Ex

Employee (object)
EmployeeControl ler

you should not marry the db of choice to your code, this is why people
seperate the "BusinessLo gic" layer and the DataAccess layer.

See

http://sholliday.spaces.live.com/blog/
6/5/2006
Custom Objects and Tiered Development II // 2.0

"John Kraft" <jhkr...@barbec ueguy.comwrote in message

news:06******** *************** *********@4ax.c om...

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);

}
}- Hide quoted text -

- Show quoted text -

[Tom Dacon]

A good rule to follow, someone once said, is that when you're tempted to
create a class with Manager or Controller in the name, you're probably
starting to wander away from good object-oriented design principles.

Just something to think about.

Tom Dacon
Dacon Software Consulting

"sloan" <sl***@ipass.ne twrote in message
news:Ob******** ******@TK2MSFTN GP06.phx.gbl...

>
You should not mix the object's code, with the code that creates the
objects.

Instead, you push that code into a Manager or Controller class.

Ex

Employee (object)
EmployeeControl ler

you should not marry the db of choice to your code, this is why people
seperate the "BusinessLo gic" layer and the DataAccess layer.

See

http://sholliday.spaces.live.com/blog/
6/5/2006
Custom Objects and Tiered Development II // 2.0

"John Kraft" <jh*****@barbec ueguy.comwrote in message
news:06******** *************** *********@4ax.c om...

>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
inexperience d 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
connectionStri ng; } 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);

}
}

[Bruce Wood]

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

Ignore the troll.

On Mar 20, 6:01 pm, "Susie DBA [MSFT]" <susie...@hotma il.comwrote:

Sloan

I don't agree with that.

Maybe you need to learn how to write SQL Server

there is only one database that matters; and it has been this way for
10 years

On Mar 20, 4:33 pm, "sloan" <[e-mail] wrote:

You should not mix the object's code, with the code that creates the
objects.

Instead, you push that code into a Manager or Controller class.

Ex

Employee (object)
EmployeeControl ler

you should not marry the db of choice to your code, this is why people
seperate the "BusinessLo gic" layer and the DataAccess layer.

See

http://sholliday.spaces.live.com/blog/
6/5/2006
Custom Objects and Tiered Development II // 2.0

"John Kraft" <jhkr...@barbec ueguy.comwrote in message

news:06******** *************** *********@4ax.c om...

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);

}
}

[Bruce Wood]

On Mar 20, 3:20 pm, John Kraft <jhkr...@barbec ueguy.comwrote:

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);

}

}

One immediately obvious problem is that if you make the data access
methods static then you can't take advantage of polymorphism. At
least, not in C#.

[bob]

Hi,
I think the flexibility of the datalayer should be considered
valuable.
I recently had a mature project that was based on SQlServer and we had
to deploy it on SQLAnywhere.
I altered the datalayer to use a data factory and with a workable
amount of modification the Application was up and away.
Hate to think of the effort involved if I had to rummage around in
the business objects.
To me it comes down to what the app is going to do. If it is quick and
dirty then I'll use data aware objects straight on the GUI if I can
get away with it, but otherwise I stick with 3 tier.
Bob

[Christof Nordiek]

Hi John,

some ideas:
since you will use only one database (atleast not one database per class),
you could put the connectionstrin g in a single class (maybe static class),
instead of making it a property of each class.

The Load method shouldn't use a ref-parameter, better is to return the
created instance as return-value.
(If you still want to use a parameter, it should be an out parameter. Then
you don't have to assign a value, wich will be overidden anyway.)

Maybe you should provide a private constructor, wich is called by the Load
method. The public constructor can remain for the object creation. But also
a Create-method could be possible.

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

Think of a way to load a list from the database. Maybe with the option of
deferred loading, but that's not easy to implement.

Another option in general is to use an OR-Mapper. They do much of the work
for you and work better than anything, you can develop in a short time.

HTH
Christof

"John Kraft" <jh*****@barbec ueguy.comschrie b im Newsbeitrag
news:06******** *************** *********@4ax.c om...

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);

}
}

[Ben Voigt]

"Tom Dacon" <td****@communi ty.nospamwrote in message
news:ut******** ******@TK2MSFTN GP03.phx.gbl...

>A good rule to follow, someone once said, is that when you're tempted to
create a class with Manager or Controller in the name, you're probably
starting to wander away from good object-oriented design principles.

Well, in this case the additional class in question would be a Persister,
and other aspects of control/management should also have their own classes.

Still, applying dependency inversion by splitting out the database access
code with a well-defined interface is valuable in such a situation, to
enhance testing, reusability, and breakage from changing the data layer.

>
Just something to think about.

Tom Dacon
Dacon Software Consulting

"sloan" <sl***@ipass.ne twrote in message
news:Ob******** ******@TK2MSFTN GP06.phx.gbl...

>>
You should not mix the object's code, with the code that creates the
objects.

Instead, you push that code into a Manager or Controller class.

Ex

Employee (object)
EmployeeContro ller

you should not marry the db of choice to your code, this is why people
seperate the "BusinessLo gic" layer and the DataAccess layer.

See

http://sholliday.spaces.live.com/blog/
6/5/2006
Custom Objects and Tiered Development II // 2.0

"John Kraft" <jh*****@barbec ueguy.comwrote in message
news:06******* *************** **********@4ax. com...

>>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
inexperienc ed 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
connectionStr ing; } 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);

}
}

[John Kraft]

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

>Hi John,

some ideas:
since you will use only one database (atleast not one database per class),
you could put the connectionstrin g in a single class (maybe static class),
instead of making it a property of each class.

The Load method shouldn't use a ref-parameter, better is to return the
created instance as return-value.
(If you still want to use a parameter, it should be an out parameter. Then
you don't have to assign a value, wich will be overidden anyway.)

Maybe you should provide a private constructor, wich is called by the Load
method. The public constructor can remain for the object creation. But also
a Create-method could be possible.

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

Think of a way to load a list from the database. Maybe with the option of
deferred loading, but that's not easy to implement.

Another option in general is to use an OR-Mapper. They do much of the work
for you and work better than anything, you can develop in a short time.

HTH
Christof

Christoff (and othesr that have answered my question),

I did the load method that way on purpose. I had a counterpart to it
in there called Create() that did what you are saying, but I removed
it because it didn't really fit into what I was trying to do; even if
it is a better design. (see more on this later)

Essentially, I was trying to make the classes easier to use. Most of
the time when we use objects like this, we simply use them as data
object; that is, we don't do database ops on them. The Load method
was intended to fill an instance that already existed. My goal was
to allow something like this...

Class1.Connecti onString = connectionStrin g;
Class1 c1 = new Class1();
c1.F1 = 5;
c1.F2 = 6;
.... etc
Class1.Save(c1) ;
If I were to use the Controller method that was suggested by others,
it would look something like...

Class1Controlle r class1Controlle r = new
Class1Controlle r(connectionStr ing);

Class1 c1 = class1Controlle r.Create();
c1.F1 = 5;
c1.F2 = 6;
class1Controlle r.Save(c1);

At cursory glance, the Controller option only looks like slightly more
typing. However, if I have 50 data object classes that are all
intereacting and I'm dealing with, my overhead just went from 50 -->
100 classes I gotta deal with. That's gonna make my app look like a
Los Angeles Expressway at rush hour. Even if I make the Controller
classes themselves static, I'll remove the constructor but have to add
in a property to set the connectionstrin g.

It's going to be especially bad, if my classes are members of another
class... like a property of a Vendor object might be a VendorContact
object that has a property of a VendorContactTy pe object.

It could very well be my inexperience, but I've been looking into
several different design ideas; and they all seem so convoluted and
overblown for anything I've ever done. I do appreciate the comments
by everyone though.
Back to the Load method you mentioned. That's just one of my quirky
Idiosyncrasies. I'm a huge believer that a method should do ONLY what
it says it's going to do...

Create should simply create.
Load should simply load, not create and then load.
Save should simply save, not save and then refresh/reload.
etc.

I hate stuff that happens "by magic." A good example is a method I
once ran into called "PrintPO." Any guesses as to what it did? I'll
tell ya. It printed the po, faxed the po to the vendor, emailed to
the vendor, updated the database, emailed a group of people a
notification, and a few other minor things. I simply wanted to print
a copy of the po to look at, and the next thing I knew I had ordered
several thousand dollars worth of merchandise. Oops.
Thanks for the input,

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
connectionStri ng; } 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);

}
}