Crud设计问题 [英] Crud Design Question
问题描述
朋友们，
我正在研究一些粗鲁的东西，而我正在寻找关于
主题的意见。下面，我粘贴了一些非常简单的示例代码。 Class2
是传统的 crud类型的对象。在一个真实的例子中，这些对象
可能会使用常见的
方法实现某种ICrud接口。
我'但是，我发现很多次，我想使用这些对象作为简单的数据对象，而且我不需要所有的数据库功能。
我不喜欢我不想担心设置连接等;并且
当我只想设置
属性时，我讨厌看到所有的方法。
更常见的解决方案是将简单的数据对象传递给数据访问类/ layer / other-buzzword。然而，当处理大量物品和没有经验的设计师（像我一样）时，这种方法会变得混乱。
我想出的一个想法是混合。这两个概念。从本质上讲，
会在对象中保留数据访问权限，但是这些方法都是静态的;
就像Class1一样。这样做的好处是允许我将对象作为一个简单的数据对象处理，然后让我获得完整的数据可访问性，而不必实例化/引用更多的类。
我的问题是，Class1
方法有什么根本性的错误吗？在
rump-roast中有什么东西真的会咬我吗？它似乎工作，我没有遇到问题
呢;但我从零开始设计非常新。
代码是C＃,. NET 2.0，VS2005
我应该注意到我只是在玩与
设计概念。这不是任何真实的东西。现在。
意见请。
谢谢，
John
公共类Class1
{
私有静态字符串connectionString;
private int id;
私有字符串名称;
public int Id {get {return id; } set {id = value; } $
public string Name {get {return name; } set {name = value; } $
公共静态字符串ConnectionString {get {return
connectionString; } set {connectionString = value; } $
public Class1（）
{
// TODO：在这里添加构造函数逻辑
}
public static void Load（ref Class1 c1，int id）
{
//在这里做填充的东西c1来自数据库
}
public static void保存（Class1 c1）
{
//在这里做东西将c1保存到数据库
}
public static void删除（Class1 c1）
{
//这里做的东西从数据库中删除c1
}
}
公共类Class2
{
private string connectionString;
private int id;
私人字符串名称;
public int Id {get {return id; } set {id = value; } $
public string Name {get {return name; } set {name = value; } $
公共字符串ConnectionString {get {return connectionString; }
set {connectionString = value; } $
public Class2（string connectionString）
{
//
// TODO ：在这里添加构造函数逻辑
//
this.connectionString = connectionString;
}
public void Load（int id）
{
//在这里填写数据库填写c1
}
public void保存（）
{
//这里做的事情是把c1保存到数据库
}
public void删除（）
{
//在这里做数据从数据库中删除c1
}
}
公共部分类Form1：表格
{
public Form1（）
{
InitializeComponent（）;
Class1.ConnectionString ="连接字符串这里的东西" ;;
Class1 c1 = new Class1（）;
Class1.Load（ref c1,42）;
Class2 c2 = new Class2（）;
c2.ConnectionString ="连接字符串在这里&qu ot ;;
c2.Load（42）;
}
}
您不应该将对象的代码与创建
对象的代码混合在一起。
相反，您将该代码推送到Manager或Controller类中。
Ex
员工（对象）
EmployeeController
你不应该把你选择的数据库与你的代码结合起来，这就是为什么人们将b / b分离为BusinessLogic的原因。 ;图层和DataAccess图层。
请参阅
http://sholliday.spaces.live.com/blog/
6/5/2006
自定义对象和分层发展II // 2.0
" John Kraft" < jh ***** @ barbecueguy.comwrote in message
news：06 ************************* ******* @ 4ax.com ...
朋友，
我正在努力一些粗鲁的东西，我正在寻找关于
主题的意见。下面，我粘贴了一些非常简单的示例代码。 Class2
是传统的 crud类型的对象。在一个真实的例子中，这些对象
可能会使用常见的
方法实现某种ICrud接口。
我'但是，我发现很多次，我想使用这些对象作为简单的数据对象，而且我不需要所有的数据库功能。
我不喜欢我不想担心设置连接等;并且
当我只想设置
属性时，我讨厌看到所有的方法。
更常见的解决方案是将简单的数据对象传递给数据访问类/ layer / other-buzzword。然而，当处理大量物品和没有经验的设计师（像我一样）时，这种方法会变得混乱。
我想出的一个想法是混合。这两个概念。从本质上讲，
会在对象中保留数据访问权限，但是这些方法都是静态的;
就像Class1一样。这样做的好处是允许我将对象作为一个简单的数据对象处理，然后让我获得完整的数据可访问性，而不必实例化/引用更多的类。
我的问题是，Class1
方法有什么根本性的错误吗？在
rump-roast中有什么东西真的会咬我吗？它似乎工作，我没有遇到问题
呢;但我从零开始设计非常新。
代码是C＃,. NET 2.0，VS2005
我应该注意到我我只是在玩弄b
设计概念。这不是任何真实的东西。现在。
意见请。
谢谢，
John
公共类Class1
{
私有静态字符串connectionString;
private int id;
私有字符串名称;
public int Id {get {return id; } set {id = value; } $
public string Name {get {return name; } set {name = value; } $
公共静态字符串ConnectionString {get {return
connectionString; } set {connectionString = value; } $
public Class1（）
{
// TODO：在这里添加构造函数逻辑
}
public static void Load（ref Class1 c1，int id）
{
//在这里做填充的东西c1来自数据库
}
public static void保存（Class1 c1）
{
//在这里做东西将c1保存到数据库
}
public static void删除（Class1 c1）
{
//这里做的东西从数据库中删除c1
}
}
公共课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; } $
公共字符串ConnectionString {get {return connectionString; }
set {connectionString = value; } $
public Class2（string connectionString）
{
//
// TODO ：在这里添加构造函数逻辑
//
this.connectionString = connectionString;
}
public void Load（int id）
{
//在这里填写数据库填写c1
}
public void保存（）
{
//这里做的事情是把c1保存到数据库
}
public void删除（）
{
//在这里做数据从数据库中删除c1
}
}
公共部分类Form1：表格
{
public Form1（）
{
InitializeComponent（）;
Class1.ConnectionString ="连接字符串这里的东西" ;;
Class1 c1 = new Class1（）;
Class1.Load（ref c1,42）;
Class2 c2 = new Clas s2（）;
c2.ConnectionString ="连接字符串这里的东西;
c2.Load（42）;
}
}
斯隆
我不喜欢不同意。
也许你需要学习如何编写SQL Server
只有一个数据库很重要;这已经是这种方式了....
10年
3月20日下午4:33，sloan < s ... @ ipass.netwrote：
你不应该将对象的代码与创建
$ b的代码混合在一起$ b对象。
相反，您将该代码推送到Manager或Controller类中。
Ex
员工（对象）
EmployeeController
您不应该将选择的数据库与您的代码结合，这就是为什么人们
分离BusinessLogic和BusinessLogic。图层和DataAccess图层。
请参阅
http://sholliday.spaces.live.com/blog/
6/5/2006
自定义对象和分层发展II // 2.0
" John Kraft" < jhkr ... @ barbecueguy.comwrote in message
新闻：06 *********************** ********* @ 4ax.com ...
朋友，
我正在研究一些粗俗的东西，而我正在寻找关于
主题的意见。下面，我粘贴了一些非常简单的示例代码。 Class2
是传统的 crud类型的对象。在一个真实的例子中，这些对象
可能会使用常见的
方法实现某种ICrud接口。
我发现很多次，我想将这些对象用作简单的数据对象，而且我不需要所有的数据库功能。
我不想担心设置连接等等;并且
当我只想设置
属性时，我讨厌看到所有的crud方法。
更常见的解决方案是将简单的数据对象传递给数据访问类/图层/
其他-流行语。然而，当处理大量物品和没有经验的设计师（像我一样）时，这种方法可能会变得混乱。
我想出的一个想法就是混合。这两个概念。从本质上讲，
会在对象中保留数据访问权限，但是这些方法都是静态的;
就像Class1一样。这样做的好处是允许我将对象作为一个简单的数据对象处理，然后让我获得完整的数据可访问性，而不必实例化/引用更多的类。
我的问题是，Class1
方法有什么根本原因吗？在
rump-roast中有什么东西真的会咬我吗？它似乎工作，我没有遇到问题
呢;但我从头开始设计非常新。
代码是C＃，.NET 2.0，VS2005
I应该也应该注意到我只是在玩
设计概念。这不是任何真实的东西。马上。
意见请。
谢谢你，
John
公共类Class1
{
private static string connectionString;
private int id;
私有字符串名称;
public int Id {get {return id; } set {id = value; } $
public string Name {get {return name; } set {name = value; } $
公共静态字符串ConnectionString {get {return
connectionString; } set {connectionString = value; }
public Class1（）
{
// TODO：添加构造函数逻辑这里
}
public static void Load（ref Class1 c1，int id）
{
//在这里填写数据库中的c1
}
public static void保存（Class1 c1）
{
//在此处执行操作以将c1保存到数据库
}
public static void删除（Class1 c1）
{
//在此处执行操作以从数据库中删除c1
}
}
公共类Class2
{
private string connectionString;
private int id;
私有字符串名称;
public int Id {get {return id; } set {id = value; } $
public string Name {get {return name; } set {name = value; } $
公共字符串ConnectionString {get {return connectionString; }
set {connectionString = value; }
public Class2（string connectionString）
{
//
// TODO：在这里添加构造函数逻辑
//
this.connectionString = connectionString;
}
public void Load（int id）
{
//在这里做填充c1的东西数据库
}
public void保存（）
{
//在这里做东西将c1保存到数据库
}
public void Delete（）
{
//在这里做数据从数据库中删除c1
}
}
public partial class Form1：Form
{
public Form1（）
{
InitializeComponent（）;
Class1.ConnectionString ="这里的连接字符串&;;
Class1 c1 = new Class1（）;
Class1.Load（ref c1,42）;
Class2 c2 = new Class2（）;
c2.ConnectionString =" connection string stuff here ;;
c2.Load（42）;
}
} - 隐藏引用的文字 -
- 显示引用的文字 -
有人曾经说过，一个很好的规则是，当你想要
在名称中创建一个名为Manager或Controller的类，你可能已经开始偏离良好的面向对象设计原则了。
只需要考虑一下。
Tom Dacon
Dacon软件咨询
" sloan" ; < sl *** @ ipass.netwrote in message
news：Ob ************** @ TK2MSFTNGP06.phx.gbl ...
>
您不应该将对象的代码与创建
对象的代码混合在一起。
相反，您将该代码推送到Manager或Controller类中。
Ex
员工（对象）
EmployeeController
你不应该把你选择的数据库与你的代码结合起来，这就是为什么人们将b / b分开的原因" BusinessLogic"图层和DataAccess图层。
请参阅
http://sholliday.spaces.live.com/blog/
6/5/2006
自定义对象和分层发展II // 2.0
" John Kraft" < jh ***** @ barbecueguy.comwrote in message
news：06 ************************* ******* @ 4ax.com ...
>朋友们，
我正在研究一些问题东西，我正在寻找关于
主题的意见。下面，我粘贴了一些非常简单的示例代码。 Class2
是一个传统的 crud类型的对象。在一个真实的例子中，这些对象可能会用常见的
方法实现某种ICrud接口。
我发现很多次，但是，我想要使用这些对象作为简单的数据对象，我不需要所有的数据库功能。
我不想担心设置连接等等;当我只想设置
属性时，我讨厌看到所有的crud方法。
更常见的解决方案是拥有简单的数据对象
传递给数据访问类/ layer / other-buzzword。然而，当处理大量物品和没有经验的设计师（像我一样）时，这种方法会变得混乱。
我想出的一个想法是混合。这两个概念。从本质上讲，
将数据访问保留在对象中，但使方法全部静态;类似于Class1。这样做的好处是可以让我将对象视为一个简单的数据对象，但却让我无需实例化/引用更多的类。
我的问题是，Class1
方法有什么根本原因吗？什么东西真的会咬我的肚腩烤？它似乎工作，我还没有遇到问题
但我从零开始设计非常新。
代码是C＃,. NET 2.0，VS2005
我可能还应该注意到我只是在玩
设计理念。这不是任何真实的东西。现在。
意见请。
谢谢，
约翰
公共课Class1
{
private static string connectionString;
private int id;
私有字符串名称;
public int Id {get {return id; } set {id = value;公共字符串名称{get {return name; } set {name = value;公共静态字符串ConnectionString {get {return
connectionString; } set {connectionString = value;公共Class1（）
//
// TODO：在这里添加构造函数逻辑
public static void Load（ref Class1 c1，int id）
//
//在这里填写数据库中的c1
}
公共静态无效保存（Class1 c1）
{
//在此处将c1保存到数据库中
}
public static void删除（Class1 c1）
//
//这里的东西从数据库中删除c1
}
}
公共类Class2
{
私有字符串连接字符串;
private int id;
私有字符串名称;
public int Id {get {return id; } set {id = value;公共字符串名称{get {return name; } set {name = value;公共字符串ConnectionString {get {return connectionString; }
设置{connectionString = value;公共Class2（字符串connectionString）
{
//
// TODO：在这里添加构造函数逻辑
//
这个.connectionString = connectionString;
}
public void Load（int id）
//
//在这里填写数据库中的c1
}
public void保存（）
//
//将数据保存到数据库中
}
public void删除（ ）
//
//从这里做数据从数据库中删除c1
}
公共部分类Form1：表格
{
public Form1（）
{InitialifyComponent（）;
Class1.ConnectionString ="连接字符串这里的东西" ;;
Class1 c1 = new Class1 （）;
Class1.Load（ref c1,42）;
Class2 c2 = new Class2（）;
c2.ConnectionString =" connection string stuff here; < br。> c2.Load（42）;
}
}
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);
}
}解决方案
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);
}
}
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 -
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);
}
}
这篇关于Crud设计问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
