Re: Crud Design Question
- From: "Christof Nordiek" <cn@xxxxxxxxx>
- Date: Wed, 21 Mar 2007 09:03:02 +0100
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" <jhkraft@xxxxxxxxxxxxxxx> schrieb im Newsbeitrag
news:06m0031v5htl2oigksin71n6hs4psg1811@xxxxxxxxxx
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);
}
}
.
- Follow-Ups:
- Re: Crud Design Question
- From: John Kraft
- Re: Crud Design Question
- From: John Kraft
- Re: Crud Design Question
- References:
- Crud Design Question
- From: John Kraft
- Crud Design Question
- Prev by Date: DROPDOWN SELECTEDINDEX PROBLEM
- Next by Date: Re: DROPDOWN SELECTEDINDEX PROBLEM
- Previous by thread: Re: Crud Design Question
- Next by thread: Re: Crud Design Question
- Index(es):
Relevant Pages
|