代码之家 › 专栏 › 技术社区 › Igor Zelaya

数据集应该位于N层(多层)架构中的什么位置?

n-tier dataset architecture .net

Igor Zelaya · 技术社区 · 17 年前

我们目前正在讨论数据集是否应该进入数据层或业务层?

我的朋友认为所有ADO.NET组件都应该放在数据层中。对我来说,这似乎不正确,原因如下:

我认为数据集和数据表应该在业务逻辑中,因为它们对所有数据提供者都是通用的。数据层应该有一个提供程序工厂,用于实例化正确的提供程序对象(连接、数据适配器、事务、数据读取器等)。对于我来说,这是一种方式,原因如下:

一些N层的专家能帮我们扫清障碍吗?提前谢谢

6 回复 | 直到 17 年前

Joel Coehoorn 17 年前

在这里,我们将数据集、数据表、数据行和数据阅读器从数据层返回到业务层。

基本原理是这些类型不是特定于DB风格的。无论您使用的是MySQL、Access、SQL Server、Oracle,还是任何数据集都是数据集,因此可以从根级数据层返回。

然后,业务层获取这些原始数据,并将其转换为强类型业务对象(应用任何必要的业务规则)以提交到表示层。

编辑: 当我查看一些代码时,我们不太使用完整的数据集。它主要是数据表和数据阅读器。

John Saunders 17 年前

在我看来,根本不要使用数据集。甚至不要使用类型化数据集。这些是在LINQ之前创建的旧构造。跳过古代历史,进入现在时态:使用linq到实体和实体框架(ef)。两者关系密切,但不尽相同。

不要跨服务边界公开EF实体。不幸的是,微软选择在序列化实体时公开实现细节。除此之外,使用ef,比使用dataset有趣得多。

Sylvain Rodrigue 17 年前

隔离数据访问并不是什么新鲜事:我们15年前就这么做了(是的,15年前!).

我在很多地方工作过,看到了很多孤立的数据层。

但我从来没有——从来没有!--看到数据源被替换了!

是的,我看了两次:两次,我们还替换了oudded数据层和所有toping软件…

我的回答很简单:除非你是在为搁置软件工作,否则你可以隔离尽可能多的数据层,你什么都不用做。

因为没有人会因为更改而更改SQL Server或Oracle。因为有人会这么做,所以他们要么重写软件,要么让舒尔知道他们所购买的产品与他们所剩下的产品兼容。

在我的书中,任何数据层都是愚蠢的。

如果你不同意,就告诉我,在你的生活中,这一层什么时候能为某人节省美元……

Bayard Randel 17 年前

典型的方法是在业务逻辑层/域中公开聚合根(如客户)存储库接口,并在数据访问层/基础结构中实现具体的存储库。

Andrew Shepherd 17 年前

我对数据集的基本问题是,它们的结构是数据库模式的精确镜像。

如果您将数据集公开给实际的页面呈现代码,那么您将有效地将数据库模式(产品的最终后端)公开给表示层。现在明显的问题可能会发生:稍后,您将希望重新构建底层数据模式,并且由于设计的原因,您需要将更改应用到系统中的所有其他层。这是一个封装的主要例子,在实际应用时没有使用它。

如果要使用数据集,请将数据集直接隐藏在数据访问层中,并向表示层公开业务对象的概念集。您公开的业务对象集应该根据良好的面向对象原则进行设计,这与良好的关系数据库设计原则完全不同。

-1

Aaron 17 年前

我不得不同意根本不使用数据集。我处理的其中一个应用程序在数据层和应用程序层都有数据集。数据层数据集与应用层数据集将信息非规范化的数据库相匹配,从而使前端更易于使用。