DAL设计问题和传递数据集 [英] DAL design question and passing datasets

问题描述

大家好，


我正在设计一个n层应用程序，对我的
$ b $有一些疑问b设计。


我创建了一个连接数据库的数据访问层（SQL

Server）并执行选择，更新，删除和插入。我使用数据集

对象将数据传入和传出DAL。


在我的GUI（Windows窗体）中，我使用数据绑定将控件绑定到数据表

从DAL返回的数据集中。


为了数据绑定控件，我必须在
$ b中包含列名我希望绑定的$ b数据表。这些名称直接来自

数据库，这意味着我的GUI具有知识。关于数据库字段。我认为

这是不可取的。应如何处理？我应该使用强大的

类型数据集吗？


感谢任何帮助！


谢谢。

解决方案

" Peter M." < Pe的***************** @ chello.nl>在消息中写道

news：d1 ************************** @ news.chello.nl ..。< blockquote class =post_quotes>
大家好，

我正在设计一个n层应用程序，对我的设计有一些疑问。
<我创建了一个数据访问层，它连接到数据库（SQL
服务器）并执行选择，更新，删除和插入。我使用数据集
对象来传递DAL数据。

在我的GUI（windows窗体）中，我使用数据绑定将控件绑定到数据集中的数据表中。从DAL返回。

为了数据绑定控件，我必须在我希望绑定的
数据表中包含列名。这些名称直接来自
数据库，这意味着我的GUI具有知识。关于数据库字段。我认为这不可取。应如何处理？我应该使用
强类型数据集吗？

那么GUI应该具有knoledge关于数据。等级是关于控制

知识和耦合，而不是消除它们。用户界面应该知道

设计时间，并且能够在运行时发现UI负责的每个数据的名称，类型和基本

约束信息

显示或编辑。


现在，列名是否直接来自数据库。取决于您。

您从UI绑定的服务接口返回某种数据（实体和集合，或行和表）

。那些实体和

操作它们的公共方法就是你所知道的所有知道。如果你改变那些服务接口定义，包括更改

实体元数据，你应该会打破你的用户界面。


是的，强类型数据集通常适用于非强类型的b $ b类型数据集，因为除其他外，它们使耦合显式和编译器可见。这使得传播更改更容易，并用编译时更改了运行时错误。


David

彼得M. < Pe的***************** @ chello.nl> écritdansle message de news：

d1**************************@news.chello.nl。 ..


|我创建了一个连接数据库的数据访问层（SQL

| Server），并执行选择，更新，删除和插入。我使用数据集

|将数据传入和传出DAL的对象。


我已经设计了DAL几年了，我会评论你

真的不应该在任何地方传递数据集;它们应该是公平的，并且直接隐藏在DAL中。


|在我的GUI（Windows窗体）中，我使用数据绑定将控件绑定到

数据表

|在从DAL返回的数据集中。


理想情况下，在这个n层方案中，数据库表应该在DAL

和UI中应该连接到位于

中间的业务对象。


..NET数据感知控件可以绑定到对象和列表对象;那里

真的没有必要把桌子拿出DAL只是连接到

控件;这是旧的VB / Delphi服务方式。


没有理由为什么用户界面不应该知道他们正在显示哪些属于哪个属性的b $ b类。 DAL应该将属性和类映射到

用于保存业务对象的表和字段。


查看关于OPF的文章网站 www.carterconsulting.org.uk


Joanna


-

Joanna Carter [TeamB]

顾问软件工程师

> .NET数据感知控件可以绑定到对象和对象列表;有

真的不需要将表格从DAL中取出来连接到
控件;这是旧的VB / Delphi服务方式。

我完全同意这一点，我已经工作了2年，并且我经常使用ADO.NET
当试图让我的业务从$ ADB.NET对象继承时，我遇到了麻烦。我经常遇到的麻烦是因为DataRow只能在一个DataTable等限制而造成

。因为

大约6个月后我创建了自己的业务对象而我甚至没有不要使用

DataSets和DataTables，甚至不在我的DAL中。

没有理由为什么用户界面不应该知道哪些属性属于哪个类？正在展示。 DAL应该将属性和类映射到用于保存业务对象的表和字段。

再次，我完全同意，n层背后的想法设计是一个自上而下的
架构。最上层的班级知道关于接口的所有内容。

下面的类。因此，您的GUI确实知道哪些列可以在DAL的输出中找到
。但de DAL现在没有关于GUI的任何内容......这是一个单向的方向。

Hi all,

I''m currently designing an n-tier application and have some doubts about my
design.

I have created a Data Access layer which connects to the database (SQL
Server) and performs Select, update, delete and inserts. I use dataset
objects to pass data to and from the DAL.

In my GUI (windows forms), I use databinding to bind controls to a datatable
in the datasets which are returned from the DAL.

In order to databind controls, I must include the column names in the
datatable to which I wish to bind. These names come directly from the
database, which means my GUI has "knowledge" about database fields. I think
this is not desirable. How should this be handled? should I use strongly
typed datasets instead?

any help is appreciated!

thanks.

解决方案

"Peter M." <Pe*****************@chello.nl> wrote in message
news:d1**************************@news.chello.nl.. .

Hi all,

I''m currently designing an n-tier application and have some doubts about
my design.

I have created a Data Access layer which connects to the database (SQL
Server) and performs Select, update, delete and inserts. I use dataset
objects to pass data to and from the DAL.

In my GUI (windows forms), I use databinding to bind controls to a
datatable in the datasets which are returned from the DAL.

In order to databind controls, I must include the column names in the
datatable to which I wish to bind. These names come directly from the
database, which means my GUI has "knowledge" about database fields. I
think this is not desirable. How should this be handled? should I use
strongly typed datasets instead?

Well the GUI should have "knoledge" about data. Tiers are about controling
knoledge and coupling, not eliminating them. The UI should know at
design-time, and be able to discover at runtime the name, type and basic
constraint information about every piece of data the UI is responsible for
displaying or editing.

Now whether the column names come "directly from the database" is up to you.
You return some sort of data (entities and collections, or rows and tables)
from the service interfaces to which the UI is bound. Those entities and
the public methods which operate on them is all your UI "knows". If you
change those service interface definitions, which includes changing the
entity metadata, you should expect to break your UI.

And yes, strongly typed datasets are generally perferable to non-strongly
typed ones because, among other things, they make coupling explicit and
visible to the compiler. This makes propagating changes easier and replaces
runtime errors with compile-time ones.

David

"Peter M." <Pe*****************@chello.nl> a écrit dans le message de news:
d1**************************@news.chello.nl...

| I have created a Data Access layer which connects to the database (SQL
| Server) and performs Select, update, delete and inserts. I use dataset
| objects to pass data to and from the DAL.

Having been designing DALs for a few years now, I would comment that you
really shouldn''t be passing datasets anywhere; they should be fairly and
squarely hidden inside the DAL.

| In my GUI (windows forms), I use databinding to bind controls to a
datatable
| in the datasets which are returned from the DAL.

Ideally, in this n-tier scenario, the database tables should be in the DAL
and the UI should connect to the business objects which reside "in the
middle".

..NET data-aware controls can be bound to objects and lists of objects; there
really is no need to bring the tables out of the DAL just to connect to
controls; this is the old VB/Delphi way of doing things.

There is no reason why the UI should not know which properties of which
class they are displaying. The DAL should map the properties and classes to
the tables and fields used to persist the business objects.

Take a look at the articles on OPFs on my site www.carterconsulting.org.uk

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

> .NET data-aware controls can be bound to objects and lists of objects; there

really is no need to bring the tables out of the DAL just to connect to
controls; this is the old VB/Delphi way of doing things.
I can fully agree with that, I have been working for 2 years with
ADO.NET and I have often had troubles when trying to let my bussiness
objects inherit from ADO.NET objects. Troubles I often had, were caused
by restrictions like a DataRow can only be in one DataTable etc. Since
about 6 months I create my own business objects and I even don''t use
DataSets and DataTables, even not inside my DAL.
There is no reason why the UI should not know which properties of which
class they are displaying. The DAL should map the properties and classes to
the tables and fields used to persist the business objects.

Again, I can fully agree, the idea behind an n-tier design is a top-down
architecture. The class on top knows everything about the ''interfaces''
of the classes under it. So your GUI does know which columns there are
to be found in the output of the DAL. But de DAL does not now anything
about the GUI... It is an one-way direction.

这篇关于DAL设计问题和传递数据集的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！