数据/业务对象层最佳实践 [英] Data/Business Object Tier Best Practices

问题描述

我正在VB.NET中开发一个Windows窗体应用程序，它将使用.NET

远程访问来访问数据层类。


非常简单我想出的方法是创建类型化的（.xsd）数据集。

例如dsParts.xsd并包括数据层中的数据集。然后我将

创建一个看起来像这样的类

公共类CPart

继承dsParts

Public Sub New （ByVal iPartID as Integer）

Dim cm As New OleDb.OleDbCommand

cm.CommandType = CommandType.Text

cm.CommandText ="从tblParts中选择*，其中PartID =" &

iPartID

modData.FillDataTable（cm，Me.tblParts，ConnectionStrings.QASpec）

''填充数据表是一种常用方法我在其中传递一个命令

和连接字符串

''它然后用结果填充传递的表对象（ByRef）

命令

''如果这个xml数据

架构有多个表，我可以填写1个以上的数据表

''我可以现在为CPart添加更多方法并覆盖

基础数据集的方法（如果需要）

''CPart是一个可用于代替标准的数据源

数据集对象非常适合数据绑定


''我还没有做的一件事是覆盖或添加

其他方法基础基类中的其他表类

''不确定我将如何完成该部分。

结束子

结束类


对我来说这是一个SIM卡创建数据类的方法因为你可以通过将表从服务器资源管理器直接拖到表格中来轻松地创建XML模式。然后，当您继承XML数据模式（键入

数据集）时，您将所有表字段作为类中的属性，默认为

。

任何其他方式做它似乎很多工作。其他方式是

来创建数据类并手动输入每个字段作为属性。你没有得到你的数据绑定功能（虽然我听说有一种方法可以在运行时使这些绑定成为可能）。你肯定不会得到的一件事是设计

时间数据绑定（上面提到的另一种方法，我们可以轻松地将类型化的

数据集绑定到我们的第三方网格控件设计时间。）


然后使用您的数据类，您必须在集合中实现它们。对于

示例CPart和CPart，将是两个不同的类。继承一个

类型的数据集，似乎很多这项工作都是为你完成的，

项目可以在几个月前完成。


你们觉得怎么样？这是一种公认​​的做法吗？还是我离开了？

在这里？还有其他选择吗？优点缺点？我正在寻找建议

因为我必须尽快决定数据层的设计。


感谢您的意见。


D.

I am developing a Windows Forms application in VB.NET that will use .NET
remoting to access the data tier classes.

A very simple way I have come up with is by creating typed (.xsd) datasets.
For example dsParts.xsd and including that in the data tier. I then will
create a class that looks like this
Public Class CPart
Inherits dsParts
Public Sub New(ByVal iPartID as Integer)
Dim cm As New OleDb.OleDbCommand
cm.CommandType = CommandType.Text
cm.CommandText = "Select * from tblParts where PartID=" &
iPartID
modData.FillDataTable(cm, Me.tblParts, ConnectionStrings.QASpec)
''Fill data table is a common method where i pass in a command
and connection string
''it then fills the passed table object (ByRef) with the results
of the command
''I could fill more than 1 data table here if this xml data
schema had more than one table
''I can now add more methods to CPart and overide methods of the
underlying dataset if required
''CPart is a datasource which can be used in place of a standard
dataset object which is great for data binding

''One thing I haven''t got to yet is Overriding or adding
additional methods to the other table classes in the underlying baseclass
''not sure how I will accomplish that part.
End Sub
End Class

To me this is a simple way of creating your dataclasses because you can
create your XML schema easily by dragging tables from the server explorer
directly on to the schema. Then when you Inherit the XML data schema (typed
dataset) you get all of the table fields as properties in your class by
default.

Doing it any other way just seems like A LOT OF WORK. Other ways would be
to create data classes and manually type in every field as a property. You
do not get your databinding capability (though I hear there is a way to make
these bindable at runtime). One thing you definatly won''t get is design
time databinding (the other method mentioned above, we can bind the typed
datasets to our 3rd party grid controls easily at design time. )

Then with your dataclasses you have to implement them in a collection. For
example CParts and CPart, would be two different classes. Inheriting from a
typed dataset just seems like a lot of this work is done for you and the
project can be completed months earlier.

What do you guys think? Is this an accepted practice? or am I way off
here? Are there other alternatives? Pro''s/Con''s? I am looking for advice
on this as I have to decide soon on the design of the data tier.

Thanks for your input.

D.

推荐答案

是否使用Typed Datasets或Custom Entity对象是一个有争议的问题
主题。我的经验法则是在情境调用

时使用Typed DataSet，并考虑在适当的时候使用Custom实体对象。我选择使用Typed DataSet时的大部分时间是因为使用它们可以提高效率，并且很多开发人员习惯于在关系模型中进行编程。 />
如果你想要对你的数据强制实施很多

业务规则，自定义实体类和集合很有用。


我对你的代码唯一的问题是我会考虑将你所拥有的类型化数据集类中的SQL语句分解出来并将其移到

a单独的类中。 />

一些资源
http://msdn.microsoft.com/asp.net/de...CustEntCls.asp
http://www.codeproject.com/dotnet/In...romDataSet.asp


" D Witherspoon"写道：

Whether to use Typed Datasets or Custom Entity objects is a controversial
topic. My rule of thumb is to use Typed DataSets when the situation calls
for it and consider using Custom entity objects when appropriate. Most of
the time I opt for Typed DataSets because it can be more productive to use
them and a lot of developers are used to programming in a relational model.
Custom entity classes and collections are usefull when you have a lot of
business rules that you want to enforce on your data.

The only issue I have with your code is that I would consider factoring out
the SQL statement from the typed dataset class you have and moving that into
a seperate class.

Some resources
http://msdn.microsoft.com/asp.net/de...CustEntCls.asp
http://www.codeproject.com/dotnet/In...romDataSet.asp

"D Witherspoon" wrote:

我正在VB.NET中开发一个Windows Forms应用程序，它将使用.NET
远程访问来访问数据层类。

我想出一个非常简单的方法是创建类型化的（.xsd）数据集。
例如dsParts.xsd并包括数据层中的数据集。然后我将创建一个看起来像这样的类

公共类CPart
继承dsParts
Public Sub New（ByVal iPartID as Integer）
Dim cm作为新的OleDb.OleDbCommand
cm.CommandType = CommandType.Text
cm.CommandText ="选择*来自tblParts，其中PartID =" &
iPartID
modData.FillDataTable（cm，Me.tblParts，ConnectionStrings.QASpec）
''填充数据表是我传递命令的常用方法
和连接字符串
''然后用命令的结果填充传递的表对象（ByRef）
''如果这个xml数据，我可以填写1个以上的数据表
schema有多个表
''我现在可以添加更多方法到CPart并覆盖基础数据集的方法（如果需要）
''CPart是一个数据源，可用于代替一个标准的数据集对象，非常适合数据绑定

''我还没有做的一件事是覆盖或添加其他方法到其他表类中潜在的基础类
''不确定我将如何完成这一部分。
End Sub
End Class

我这是一种创建数据类的简单方法，因为您可以通过将表从服务器资源管理器直接拖到模式上来轻松创建XML模式。然后，当您继承XML数据模式（键入
数据集）时，您将所有表字段作为类中的属性默认为

以任何其他方式执行它只是看起来喜欢很多工作。其他方法是创建数据类并手动输入每个字段作为属性。你没有获得数据绑定功能（虽然我听说有一种方法可以在运行时使这些可绑定）。你肯定不会得到的一件事是设计
时间数据绑定（上面提到的另一种方法，我们可以在设计时轻松地将类型化的数据集绑定到我们的第三方网格控件。）

然后使用您的数据类，您必须在集合中实现它们。对于
示例CPart和CPart，将是两个不同的类。继承一个
类型的数据集似乎很多这项工作都是为你完成的，
项目可以在几个月前完成。

你们怎么想？这是一种公认​​的做法吗？还是我离开这里？还有其他选择吗？优点缺点？我正在寻找建议
因为我必须尽快决定数据层的设计。

感谢您的意见。

D.

I am developing a Windows Forms application in VB.NET that will use .NET
remoting to access the data tier classes.

A very simple way I have come up with is by creating typed (.xsd) datasets.
For example dsParts.xsd and including that in the data tier. I then will
create a class that looks like this
Public Class CPart
Inherits dsParts
Public Sub New(ByVal iPartID as Integer)
Dim cm As New OleDb.OleDbCommand
cm.CommandType = CommandType.Text
cm.CommandText = "Select * from tblParts where PartID=" &
iPartID
modData.FillDataTable(cm, Me.tblParts, ConnectionStrings.QASpec)
''Fill data table is a common method where i pass in a command
and connection string
''it then fills the passed table object (ByRef) with the results
of the command
''I could fill more than 1 data table here if this xml data
schema had more than one table
''I can now add more methods to CPart and overide methods of the
underlying dataset if required
''CPart is a datasource which can be used in place of a standard
dataset object which is great for data binding

''One thing I haven''t got to yet is Overriding or adding
additional methods to the other table classes in the underlying baseclass
''not sure how I will accomplish that part.
End Sub
End Class

To me this is a simple way of creating your dataclasses because you can
create your XML schema easily by dragging tables from the server explorer
directly on to the schema. Then when you Inherit the XML data schema (typed
dataset) you get all of the table fields as properties in your class by
default.

Doing it any other way just seems like A LOT OF WORK. Other ways would be
to create data classes and manually type in every field as a property. You
do not get your databinding capability (though I hear there is a way to make
these bindable at runtime). One thing you definatly won''t get is design
time databinding (the other method mentioned above, we can bind the typed
datasets to our 3rd party grid controls easily at design time. )

Then with your dataclasses you have to implement them in a collection. For
example CParts and CPart, would be two different classes. Inheriting from a
typed dataset just seems like a lot of this work is done for you and the
project can be completed months earlier.

What do you guys think? Is this an accepted practice? or am I way off
here? Are there other alternatives? Pro''s/Con''s? I am looking for advice
on this as I have to decide soon on the design of the data tier.

Thanks for your input.

D.

多年来一直在开发实体对象以表示数据和

为.NET带来相同的ORM意识形态直到我给类型化的数据集提供了机会，我可以诚实地说，ORM是一个很大的浪费时间。键入

数据集可以节省大量时间并提供自定义对象的所有好处。

开发人员只需要丢失一些他们从未使用的旧实践

开始时的好主意。您必须学习从数据对象本身分离业务规则和

验证。老学校开始尝试做的第一件事就是劫持Typed Dataset，从中继承一些类，

并尝试添加各种代码。这会让您的生活更加艰难......因为每当您使用非常优秀且生动有用的设计师来更改数据集时，都会重新创建

数据集，并且您的代码更改会丢失。数据集用于数据。

验证对象作用于数据集。数据访问对象作用于

数据集。这一切都非常干净，易于管理和高效。


此外，使用类型化数据集的好处也会涟漪到其他事物。如果你因为VB6中的经验而在.NET中使用绑定犹豫
犹豫不决

不想出现懒惰...你是失去了另一个巨大的节省时间。

.NET中的数据绑定非常好（你掌握了一些奇怪的

错综复杂...即BindingContext / BindingManager的东西）！它不应该被解雇。


有时候它适合使用ORM，但大部分都是

冗余并需要大量的开发工作来换取相对较小的b $ b小优势。如果你有一个庞大的开发团队可以处理它，那么也许它是可行的。但是，打字数据集的好处是巨大的。


只是我的2c。


" Jorge Matos"写道：

Having been developing entity objects for years to represent data and
carrying that same ORM ideology to .NET for some time until I gave typed
datasets a chance, I can honestly say that ORM is a BIG WASTE OF TIME. Typed
datasets are huge time savers and provide all the benefits of custom objects.
Developers just have to lose some of their old practices which were never
good ideas to begin with. You have to learn to seperate business rules and
validation from the data object itself. One of the first thing old school
developers try to do is hijack the Typed Dataset, inherit some class from it,
and try to add all sorts of code to it. This makes your life harder... as the
dataset is recreated and your code changes lost whenever you use the very
productive and useful designer to change the dataset. Datasets are for data.
Validation objects act on the dataset. Data Access objects act on the
dataset. It''s all very clean and manageable and productive.

Also, the benefits of using typed datasets ripples to other things. if you
hesitated using binding in .NET because of your experiences in VB6 and you
don''t want to appear "lazy"... you''re losing out on another huge time saver.
Data binding in .NET is very good (one you master some of its weird
intricacies... namely the BindingContext/BindingManager stuff)! It should not
be dismissed.

There are times when its appropriate to use ORM, but for the most part it is
redundant and requires a huge development effort in exchange for relatively
minor advantages. If you have a huge development team that can handle it,
then maybe it''s the way to go. But, the benefits of typed datasets are huge.

Just my 2c.

"Jorge Matos" wrote:

是否使用Typed Datasets或Custom Entity对象是一个有争议的话题。我的经验法则是在情境调用时使用Typed DataSet，并考虑在适当的时候使用Custom实体对象。大部分时间我都选择使用Typed DataSet，因为使用它们会更高效，并且许多开发人员习惯于在关系模型中进行编程。
自定义实体类和集合是当你有很多想要对你的数据强制执行的业务规则时，这很有用。

我对你的代码唯一的问题是我会考虑分解
来自类型化数据集类的SQL语句，并将其移动到单独的类中。

一些资源：
http://msdn.microsoft.com/asp.net /de...CustEntCls.asp
http： //www.codeproject.com/dotnet/In...romDataSet.asp

D Witherspoon写道：

Whether to use Typed Datasets or Custom Entity objects is a controversial
topic. My rule of thumb is to use Typed DataSets when the situation calls
for it and consider using Custom entity objects when appropriate. Most of
the time I opt for Typed DataSets because it can be more productive to use
them and a lot of developers are used to programming in a relational model.
Custom entity classes and collections are usefull when you have a lot of
business rules that you want to enforce on your data.

The only issue I have with your code is that I would consider factoring out
the SQL statement from the typed dataset class you have and moving that into
a seperate class.

Some resources:
http://msdn.microsoft.com/asp.net/de...CustEntCls.asp
http://www.codeproject.com/dotnet/In...romDataSet.asp

"D Witherspoon" wrote:

我正在VB.NET中开发一个Windows Forms应用程序，它将使用.NET
远程访问来访问数据层类。

我想出一个非常简单的方法是创建类型化的（.xsd）数据集。
例如dsParts.xsd并包括数据层中的数据集。然后我将创建一个看起来像这样的类

公共类CPart
继承dsParts
Public Sub New（ByVal iPartID as Integer）
Dim cm作为新的OleDb.OleDbCommand
cm.CommandType = CommandType.Text
cm.CommandText ="选择*来自tblParts，其中PartID =" &
iPartID
modData.FillDataTable（cm，Me.tblParts，ConnectionStrings.QASpec）
''填充数据表是我传递命令的常用方法
和连接字符串
''然后用命令的结果填充传递的表对象（ByRef）
''如果这个xml数据，我可以填写1个以上的数据表
schema有多个表
''我现在可以添加更多方法到CPart并覆盖基础数据集的方法（如果需要）
''CPart是一个数据源，可用于代替一个标准的数据集对象，非常适合数据绑定

''我还没有做的一件事是覆盖或添加其他方法到其他表类中潜在的基础类
''不确定我将如何完成这一部分。
End Sub
End Class

我这是一种创建数据类的简单方法，因为您可以通过将表从服务器资源管理器直接拖到模式上来轻松创建XML模式。然后，当您继承XML数据模式（键入
数据集）时，您将所有表字段作为类中的属性默认为

以任何其他方式执行它只是看起来喜欢很多工作。其他方法是创建数据类并手动输入每个字段作为属性。你没有获得数据绑定功能（虽然我听说有一种方法可以在运行时使这些可绑定）。你肯定不会得到的一件事是设计
时间数据绑定（上面提到的另一种方法，我们可以在设计时轻松地将类型化的数据集绑定到我们的第三方网格控件。）

然后使用您的数据类，您必须在集合中实现它们。对于
示例CPart和CPart，将是两个不同的类。继承一个
类型的数据集似乎很多这项工作都是为你完成的，
项目可以在几个月前完成。

你们怎么想？这是一种公认​​的做法吗？还是我离开这里？还有其他选择吗？优点缺点？我正在寻找建议
因为我必须尽快决定数据层的设计。

感谢您的意见。

D.

I am developing a Windows Forms application in VB.NET that will use .NET
remoting to access the data tier classes.

A very simple way I have come up with is by creating typed (.xsd) datasets.
For example dsParts.xsd and including that in the data tier. I then will
create a class that looks like this
Public Class CPart
Inherits dsParts
Public Sub New(ByVal iPartID as Integer)
Dim cm As New OleDb.OleDbCommand
cm.CommandType = CommandType.Text
cm.CommandText = "Select * from tblParts where PartID=" &
iPartID
modData.FillDataTable(cm, Me.tblParts, ConnectionStrings.QASpec)
''Fill data table is a common method where i pass in a command
and connection string
''it then fills the passed table object (ByRef) with the results
of the command
''I could fill more than 1 data table here if this xml data
schema had more than one table
''I can now add more methods to CPart and overide methods of the
underlying dataset if required
''CPart is a datasource which can be used in place of a standard
dataset object which is great for data binding

''One thing I haven''t got to yet is Overriding or adding
additional methods to the other table classes in the underlying baseclass
''not sure how I will accomplish that part.
End Sub
End Class

To me this is a simple way of creating your dataclasses because you can
create your XML schema easily by dragging tables from the server explorer
directly on to the schema. Then when you Inherit the XML data schema (typed
dataset) you get all of the table fields as properties in your class by
default.

Doing it any other way just seems like A LOT OF WORK. Other ways would be
to create data classes and manually type in every field as a property. You
do not get your databinding capability (though I hear there is a way to make
these bindable at runtime). One thing you definatly won''t get is design
time databinding (the other method mentioned above, we can bind the typed
datasets to our 3rd party grid controls easily at design time. )

Then with your dataclasses you have to implement them in a collection. For
example CParts and CPart, would be two different classes. Inheriting from a
typed dataset just seems like a lot of this work is done for you and the
project can be completed months earlier.

What do you guys think? Is this an accepted practice? or am I way off
here? Are there other alternatives? Pro''s/Con''s? I am looking for advice
on this as I have to decide soon on the design of the data tier.

Thanks for your input.

D.

多年来一直在开发实体对象来表示数据和

携带相同的ORM意识形态.NET已经有一段时间了，直到我给类型化的

数据集一个机会，我可以诚实地说ORM是一个很大的浪费时间。键入

数据集可以节省大量时间并提供自定义对象的所有好处。

开发人员只需要丢失一些他们从未使用的旧实践

开始时的好主意。您必须学习从数据对象本身分离业务规则和

验证。老学校开始尝试做的第一件事就是劫持Typed Dataset，从中继承一些类，

并尝试添加各种代码。这会让您的生活更加艰难......因为每当您使用非常优秀且生动有用的设计师来更改数据集时，都会重新创建

数据集，并且您的代码更改会丢失。数据集用于数据。

验证对象作用于数据集。数据访问对象作用于

数据集。这一切都非常干净，易于管理和高效。


此外，使用类型化数据集的好处也会涟漪到其他事物。如果你因为VB6中的经验而在.NET中使用绑定犹豫
犹豫不决

不想出现懒惰...你是失去了另一个巨大的节省时间。

.NET中的数据绑定非常好（你掌握了一些奇怪的

错综复杂...即BindingContext / BindingManager的东西）！它不应该被解雇。


有时候它适合使用ORM，但大部分都是

冗余并需要大量的开发工作来换取相对较小的b $ b小优势。如果你有一个庞大的开发团队可以处理它，那么也许它是可行的。但是，打字数据集的好处是巨大的。


只是我的2c。


" Jorge Matos"写道：

Having been developing entity objects for years to represent data and
carrying that same ORM ideology to .NET for some time until I gave typed
datasets a chance, I can honestly say that ORM is a BIG WASTE OF TIME. Typed
datasets are huge time savers and provide all the benefits of custom objects.
Developers just have to lose some of their old practices which were never
good ideas to begin with. You have to learn to seperate business rules and
validation from the data object itself. One of the first thing old school
developers try to do is hijack the Typed Dataset, inherit some class from it,
and try to add all sorts of code to it. This makes your life harder... as the
dataset is recreated and your code changes lost whenever you use the very
productive and useful designer to change the dataset. Datasets are for data.
Validation objects act on the dataset. Data Access objects act on the
dataset. It''s all very clean and manageable and productive.

Also, the benefits of using typed datasets ripples to other things. if you
hesitated using binding in .NET because of your experiences in VB6 and you
don''t want to appear "lazy"... you''re losing out on another huge time saver.
Data binding in .NET is very good (one you master some of its weird
intricacies... namely the BindingContext/BindingManager stuff)! It should not
be dismissed.

There are times when its appropriate to use ORM, but for the most part it is
redundant and requires a huge development effort in exchange for relatively
minor advantages. If you have a huge development team that can handle it,
then maybe it''s the way to go. But, the benefits of typed datasets are huge.

Just my 2c.

"Jorge Matos" wrote:

是否使用Typed Datasets或Custom Entity对象是一个有争议的话题。我的经验法则是在情境调用时使用Typed DataSet，并考虑在适当的时候使用Custom实体对象。大部分时间我都选择使用Typed DataSet，因为使用它们会更高效，并且许多开发人员习惯于在关系模型中进行编程。
自定义实体类和集合是当你有很多想要对你的数据强制执行的业务规则时，这很有用。

我对你的代码唯一的问题是我会考虑分解
来自类型化数据集类的SQL语句，并将其移动到单独的类中。

一些资源：
http://msdn.microsoft.com/asp.net /de...CustEntCls.asp
http： //www.codeproject.com/dotnet/In...romDataSet.asp

D Witherspoon写道：

Whether to use Typed Datasets or Custom Entity objects is a controversial
topic. My rule of thumb is to use Typed DataSets when the situation calls
for it and consider using Custom entity objects when appropriate. Most of
the time I opt for Typed DataSets because it can be more productive to use
them and a lot of developers are used to programming in a relational model.
Custom entity classes and collections are usefull when you have a lot of
business rules that you want to enforce on your data.

The only issue I have with your code is that I would consider factoring out
the SQL statement from the typed dataset class you have and moving that into
a seperate class.

Some resources:
http://msdn.microsoft.com/asp.net/de...CustEntCls.asp
http://www.codeproject.com/dotnet/In...romDataSet.asp

"D Witherspoon" wrote:

我正在VB.NET中开发一个Windows Forms应用程序，它将使用.NET
远程访问来访问数据层类。

我想出一个非常简单的方法是创建类型化的（.xsd）数据集。
例如dsParts.xsd并包括数据层中的数据集。然后我将创建一个看起来像这样的类

公共类CPart
继承dsParts
Public Sub New（ByVal iPartID as Integer）
Dim cm作为新的OleDb.OleDbCommand
cm.CommandType = CommandType.Text
cm.CommandText ="选择*来自tblParts，其中PartID =" &
iPartID
modData.FillDataTable（cm，Me.tblParts，ConnectionStrings.QASpec）
''填充数据表是我传递命令的常用方法
和连接字符串
''然后用命令的结果填充传递的表对象（ByRef）
''如果这个xml数据，我可以填写1个以上的数据表
schema有多个表
''我现在可以添加更多方法到CPart并覆盖基础数据集的方法（如果需要）
''CPart是一个数据源，可用于代替一个标准的数据集对象，非常适合数据绑定

''我还没有做的一件事是覆盖或添加其他方法到其他表类中潜在的基础类
''不确定我将如何完成这一部分。
End Sub
End Class

我这是一种创建数据类的简单方法，因为您可以通过将表从服务器资源管理器直接拖到模式上来轻松创建XML模式。然后，当您继承XML数据模式（键入
数据集）时，您将所有表字段作为类中的属性默认为

以任何其他方式执行它只是看起来喜欢很多工作。其他方法是创建数据类并手动输入每个字段作为属性。你没有获得数据绑定功能（虽然我听说有一种方法可以在运行时使这些可绑定）。你肯定不会得到的一件事是设计
时间数据绑定（上面提到的另一种方法，我们可以在设计时轻松地将类型化的数据集绑定到我们的第三方网格控件。）

然后使用您的数据类，您必须在集合中实现它们。对于
示例CPart和CPart，将是两个不同的类。继承一个
类型的数据集似乎很多这项工作都是为你完成的，
项目可以在几个月前完成。

你们怎么想？这是一种公认​​的做法吗？还是我离开这里？还有其他选择吗？优点缺点？我正在寻找建议
因为我必须尽快决定数据层的设计。

感谢您的意见。

D.

I am developing a Windows Forms application in VB.NET that will use .NET
remoting to access the data tier classes.

A very simple way I have come up with is by creating typed (.xsd) datasets.
For example dsParts.xsd and including that in the data tier. I then will
create a class that looks like this
Public Class CPart
Inherits dsParts
Public Sub New(ByVal iPartID as Integer)
Dim cm As New OleDb.OleDbCommand
cm.CommandType = CommandType.Text
cm.CommandText = "Select * from tblParts where PartID=" &
iPartID
modData.FillDataTable(cm, Me.tblParts, ConnectionStrings.QASpec)
''Fill data table is a common method where i pass in a command
and connection string
''it then fills the passed table object (ByRef) with the results
of the command
''I could fill more than 1 data table here if this xml data
schema had more than one table
''I can now add more methods to CPart and overide methods of the
underlying dataset if required
''CPart is a datasource which can be used in place of a standard
dataset object which is great for data binding

''One thing I haven''t got to yet is Overriding or adding
additional methods to the other table classes in the underlying baseclass
''not sure how I will accomplish that part.
End Sub
End Class

To me this is a simple way of creating your dataclasses because you can
create your XML schema easily by dragging tables from the server explorer
directly on to the schema. Then when you Inherit the XML data schema (typed
dataset) you get all of the table fields as properties in your class by
default.

Doing it any other way just seems like A LOT OF WORK. Other ways would be
to create data classes and manually type in every field as a property. You
do not get your databinding capability (though I hear there is a way to make
these bindable at runtime). One thing you definatly won''t get is design
time databinding (the other method mentioned above, we can bind the typed
datasets to our 3rd party grid controls easily at design time. )

Then with your dataclasses you have to implement them in a collection. For
example CParts and CPart, would be two different classes. Inheriting from a
typed dataset just seems like a lot of this work is done for you and the
project can be completed months earlier.

What do you guys think? Is this an accepted practice? or am I way off
here? Are there other alternatives? Pro''s/Con''s? I am looking for advice
on this as I have to decide soon on the design of the data tier.

Thanks for your input.

D.

这篇关于数据/业务对象层最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！