J
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 "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);
}
}
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);
}
}