【问题标题】:where should datasets reside in a n-tier (multi layered) architecture?数据集应该驻留在 n 层(多层)架构中的什么位置?
【发布时间】:2010-10-24 16:11:03
【问题描述】:

我们目前正在讨论数据集应该放在数据层还是业务层?

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

  • 如果您创建一个胖数据层客户端,例如将所有内容迁移到不同的数据源将会更加困难。
  • 除非跳过业务层逻辑,否则无法绑定控件。

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

  • 迁移到不同的数据层非常简单。
  • 您可以将控件绑定到丰富的业务对象

可以请一些 n 级大师帮助我们弄清楚该走哪条路吗?

【问题讨论】:

  • 如果这只是一场辩论,我真的没有意见,它会转来转去,永远不会得到解决。如果您正在构建一个具体的项目,预算是多少?
  • @joshua。我只能说这是一个 5 位数的项目。

标签: .net architecture dataset n-tier-architecture


【解决方案1】:

在我看来,根本不要使用 DataSet。甚至不要使用类型化的 DataSet。这些是在 LINQ 之前创建的旧结构。跳过古代历史,进入现在时:使用 LINQ to Entities 和实体框架 (EF)。两者密切相关,但又不相同。

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

【讨论】:

  • 是否可以通过说为什么来参与讨论?谢谢。
  • 我对预算很感兴趣,想看看架构是什么样的,但这胜过我的看法。我记得使用类型化的数据集,那是一场噩梦。使用这些东西会像什么都没有一样咀嚼时间。我同意约翰的观点。 +1
  • +1。你是对的,也许 changig datasets 是要走的路,但这不是一个选择
【解决方案2】:

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

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

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

是的,我看过两次:两次,我们还替换了旧的数据层和所有的顶级软件......

我的答案很简单:除非你是在为搁置软件工作,否则你可以尽可能多地隔离数据层,你将一无所获。

因为没有人会为了改变而改变 SQL Server 或 Oracle。并且因为有一天有人会这样做,他们要么会重写他们的软件,要么会确保他们购买的产品与他们离开的产品兼容。

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

如果您不同意,请告诉我您一生中此层何时为某人节省了 $$$...

【讨论】:

  • 好的。我正在我的机器上编写一个应用程序来发布到一个网站。它使用 SQL Server 作为后端。然后,当我真正想要部署应用程序时,结果发现我必须支付额外费用才能使用 SQL Server。我意识到这个数据库只有不到 1000 行,虽然它保存着重要的数据,但不会经常被访问。我将其切换到 Microsoft Access 以节省资金。我真希望我没有在整个代码中使用 LinqToSQL。
  • 嗯,这可以是一个反例 :o) 也就是说,1000 行......即使是平面文件也可以完成这项工作 - 也许 SQL Server 在这里有点矫枉过正?无论如何,感谢您的评论。会考虑的。
【解决方案3】:

我们将数据集、数据表、数据行和数据读取器从数据层返回到业务层。

理由是这些类型不是特定于 db-flavor 的。无论您使用 mysql、access、sql server、oracle 还是任何数据集都是数据集,因此可以从根级数据层返回。

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


编辑:当我查看一些代码时,我们并没有太多使用完整的数据集。主要是数据表和数据读取器。

【讨论】:

    【解决方案4】:

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

    【讨论】:

      【解决方案5】:

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

      如果您将 DataSet 公开给实际的页面呈现代码,您实际上是在将数据库模式(产品的最终后端)公开给表示层。现在可能会出现明显的问题:稍后您将需要重新构建底层数据模式,并且由于设计原因,您需要将更改应用于系统中的所有其他层。这是封装在真正应该使用的时候没有被使用的一个典型例子。

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

      【讨论】:

        【解决方案6】:

        我必须同意根本不使用数据集。我在其中工作的应用程序之一是数据层和应用程序层中的数据集。 DataLayer 数据集与数据库相匹配,其中应用层数据集对信息进行了非规范化处理,使其更适合前端使用。

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 2010-09-23
          • 2015-08-22
          • 1970-01-01
          • 2012-07-11
          • 1970-01-01
          • 1970-01-01
          • 2015-05-19
          相关资源
          最近更新 更多