473,327 Members | 1,979 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,327 software developers and data experts.

Crud Design Question

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 "traditional" 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 connectionString;

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 ConnectionString { get { return
connectionString; } set { connectionString = 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 connectionString;

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 ConnectionString { get { return connectionString; }
set { connectionString = value; } }

public Class2(string connectionString)
{
//
// TODO: Add constructor logic here
//
this.connectionString = connectionString;
}

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()
{
InitializeComponent();

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

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

}
}
Mar 20 '07 #1
13 2682

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

you should not marry the db of choice to your code, this is why people
seperate the "BusinessLogic" 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*****@barbecueguy.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 "traditional" 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 connectionString;

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 ConnectionString { get { return
connectionString; } set { connectionString = 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 connectionString;

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 ConnectionString { get { return connectionString; }
set { connectionString = value; } }

public Class2(string connectionString)
{
//
// TODO: Add constructor logic here
//
this.connectionString = connectionString;
}

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()
{
InitializeComponent();

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

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

}
}

Mar 20 '07 #2
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" <s...@ipass.netwrote:
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)
EmployeeController

you should not marry the db of choice to your code, this is why people
seperate the "BusinessLogic" 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...@barbecueguy.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 "traditional" 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 connectionString;
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 ConnectionString { get { return
connectionString; } set { connectionString = 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 connectionString;
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 ConnectionString { get { return connectionString; }
set { connectionString = value; } }
public Class2(string connectionString)
{
//
// TODO: Add constructor logic here
//
this.connectionString = connectionString;
}
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()
{
InitializeComponent();
Class1.ConnectionString = "connection string stuff here";
Class1 c1 = new Class1();
Class1.Load(ref c1, 42);
Class2 c2 = new Class2();
c2.ConnectionString = "connection string stuff here";
c2.Load(42);
}
}- Hide quoted text -

- Show quoted text -

Mar 21 '07 #3
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.netwrote in message
news:Ob**************@TK2MSFTNGP06.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)
EmployeeController

you should not marry the db of choice to your code, this is why people
seperate the "BusinessLogic" 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*****@barbecueguy.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 "traditional" 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 connectionString;

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 ConnectionString { get { return
connectionString; } set { connectionString = 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 connectionString;

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 ConnectionString { get { return connectionString; }
set { connectionString = value; } }

public Class2(string connectionString)
{
//
// TODO: Add constructor logic here
//
this.connectionString = connectionString;
}

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()
{
InitializeComponent();

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

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

}
}


Mar 21 '07 #4
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...@hotmail.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" <s...@ipass.netwrote:
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)
EmployeeController
you should not marry the db of choice to your code, this is why people
seperate the "BusinessLogic" 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...@barbecueguy.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 "traditional" 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 connectionString;
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 ConnectionString { get { return
connectionString; } set { connectionString = 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 connectionString;
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 ConnectionString { get { return connectionString; }
set { connectionString = value; } }
public Class2(string connectionString)
{
//
// TODO: Add constructor logic here
//
this.connectionString = connectionString;
}
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()
{
InitializeComponent();
Class1.ConnectionString = "connection string stuff here";
Class1 c1 = new Class1();
Class1.Load(ref c1, 42);
Class2 c2 = new Class2();
c2.ConnectionString = "connection string stuff here";
c2.Load(42);
}
}
Mar 21 '07 #5
On Mar 20, 3:20 pm, John Kraft <jhkr...@barbecueguy.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 "traditional" 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 connectionString;

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 ConnectionString { get { return
connectionString; } set { connectionString = 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 connectionString;

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 ConnectionString { get { return connectionString; }
set { connectionString = value; } }

public Class2(string connectionString)
{
//
// TODO: Add constructor logic here
//
this.connectionString = connectionString;
}

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()
{
InitializeComponent();

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

Class2 c2 = new Class2();
c2.ConnectionString = "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#.

Mar 21 '07 #6
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
Mar 21 '07 #7
Hi John,

some ideas:
since you will use only one database (atleast not one database per class),
you could put the connectionstring 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*****@barbecueguy.comschrieb im Newsbeitrag
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 "traditional" 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 connectionString;

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 ConnectionString { get { return
connectionString; } set { connectionString = 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 connectionString;

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 ConnectionString { get { return connectionString; }
set { connectionString = value; } }

public Class2(string connectionString)
{
//
// TODO: Add constructor logic here
//
this.connectionString = connectionString;
}

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()
{
InitializeComponent();

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

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

}
}

Mar 21 '07 #8

"Tom Dacon" <td****@community.nospamwrote in message
news:ut**************@TK2MSFTNGP03.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.netwrote in message
news:Ob**************@TK2MSFTNGP06.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)
EmployeeController

you should not marry the db of choice to your code, this is why people
seperate the "BusinessLogic" 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*****@barbecueguy.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 "traditional" 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 connectionString;

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 ConnectionString { get { return
connectionString; } set { connectionString = 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 connectionString;

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 ConnectionString { get { return connectionString; }
set { connectionString = value; } }

public Class2(string connectionString)
{
//
// TODO: Add constructor logic here
//
this.connectionString = connectionString;
}

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()
{
InitializeComponent();

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

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

}
}



Mar 21 '07 #9
On Wed, 21 Mar 2007 09:03:02 +0100, "Christof Nordiek" <cn@nospam.de>
wrote:
>Hi John,

some ideas:
since you will use only one database (atleast not one database per class),
you could put the connectionstring 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.ConnectionString = connectionString;
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...

Class1Controller class1Controller = new
Class1Controller(connectionString);

Class1 c1 = class1Controller.Create();
c1.F1 = 5;
c1.F2 = 6;
class1Controller.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 connectionstring.

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 VendorContactType 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 connectionString;

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 ConnectionString { get { return
connectionString; } set { connectionString = 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 connectionString;

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 ConnectionString { get { return connectionString; }
set { connectionString = value; } }

public Class2(string connectionString)
{
//
// TODO: Add constructor logic here
//
this.connectionString = connectionString;
}

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()
{
InitializeComponent();

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

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

}
}
Mar 21 '07 #10

"Bruce Wood" <br*******@canada.comwrote in message
news:11**********************@n59g2000hsh.googlegr oups.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.
Mar 23 '07 #11
On Wed, 21 Mar 2007 09:03:02 +0100, "Christof Nordiek" <cn@nospam.de>
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
Mar 23 '07 #12
John Kraft <jh*****@barbecueguy.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.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Mar 24 '07 #13
On Sat, 24 Mar 2007 11:25:10 -0000, Jon Skeet [C# MVP]
<sk***@pobox.comwrote:
>John Kraft <jh*****@barbecueguy.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
Mar 25 '07 #14

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
by: andy2O | last post by:
Hello comp.lang.py, Can you help me with ideas for the following (somewhat newbie) OO design question in Python? Note, I'm using psuedo-code, not actual Python for the examples! Background:...
0
by: James Walters | last post by:
Hello, DB novice checking in here with a basic design question. I have a table called 'nms_apps' which stores information about all of our applications which we have developed/maintained for...
0
by: Krist | last post by:
Hi All, I have a database design question, pls give me some help.. I want to define tables for salesman's sales target commission . The commission could be given per EITHER sales amount of :...
1
by: Krist | last post by:
Hi All, There is some additional info I forget on this same topic I just posted. I have a database design question, pls give me some help.. I want to define tables for salesman's sales target...
1
by: dixp | last post by:
I'm new to writing multithreaded apps and I have a design question. I have a winforms app and a class which has a method that does processing which is time intensive. I want the user to be able...
3
by: reageer | last post by:
Hi all, I have a design question: I have a bunch of users (name, address, zip, etc.). They are assigned a card with a specific id. The only thing unique is this card id, or probably the...
29
by: Brad Pears | last post by:
Here is a simple OO design question... I have a Contract class. The user can either save an existing contract or they start off fresh with a blank contract, fill in the data and then save a...
9
by: fjm | last post by:
Hey everyone, I lost my internet connection for about 5 months and finally got it back. This is one of the first places I came back to. I have to say that I had a heck of a time finding it...
2
by: RoaringChicken | last post by:
Hi. Vista Ultimate Access 2007 I'm developing an inventory database and have question on design. The database stores collection details. One item in the collection, one record. The design...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.