3

多年来，3 层设计一直是我对数据库驱动应用程序的标准设计理念，它从未让我失望过。对于那些练习它的人，描述你的层次。

我发现很多人混淆了业务层和数据访问层，使其更像是 2.5 层设计。

我更喜欢使用存储过程将数据层几乎完全移动到数据库中，并且只在代码中拥有一个非常轻量级的数据层，将 sproc 调用包装到业务对象中。

你如何处理它？

编辑：如果您要做的只是定义 3 层是什么，请不要浪费时间回复。我正在寻找具体的人如何实现它，您使用存储过程还是 ORM，您如何处理 DAL 和 BLL 之间的循环依赖关系？除了说之外，这个话题还有很多深度

  • 用户界面
  • 商业
  • 数据
4

8 回答 8

2

我已经做了一段时间的主要网络应用程序，并且一直在关注 3-Tier：

UI：纯 ASPX 页面。有时实际上很难将您的业务层从这里向下推，因为在这里进行快速计算或某些事情似乎很容易做到。但是，我已经足够自律，可以确保页面背后的代码除了显示/隐藏面板、更新用户输入等之外什么都不做。

DAL：所有数据访问层的东西。我非常喜欢使用可用的 XSD/DataTable/TableAdapter 类。我还使用基于存储过程的 CRUD 方法，因此将适配器连接到存储过程很容易。

BLL：在我这里的大多数应用程序中，业务层往往是三层中最轻的，因为它们主要是 CRUD 类型的应用程序，内置了一些报告。

于 2008-09-25T16:16:32.773 回答
1

3层：

  • 数据库后端作为数据存储，我们还在数据库中强制执行依赖关系
  • C# 业务层 - 处理通过 http 提交的用户请求（由 aspx 页面接收），根据数据库的状态收集正确的响应并通过 xml 将其返回给客户端（尽管我会推荐 json）
  • javascript 前端 - 以用户友好的方式处理呈现 xml
于 2008-09-25T16:13:23.480 回答
1

我练习 3 层设计的方式与您的做法非常相似，因为我使用存储过程来处理大部分（如果不是全部）与数据库的通信。我对我的课程进行设计，以便每个课程都有特定的目的，以降低复杂性并在更改时提供更大的灵活性。

我在 3 层设计中遇到的最大问题之一是在哪里放置输入验证。很多时候，我发现自己在 UI 和业务层都重复验证，以便通过快速验证检查使用户受益，并确保进出数据层的数据是有效的。你如何处理验证？

于 2008-09-25T16:15:41.213 回答
1

更多的旁注：永远不要忘记 n 层分层是逻辑分层，而不是进程的物理分离。即，不需要让业务逻辑在与展示代码不同的进程（或不同的盒子）中运行。重要的是保持代码干净。

在物理上分离表示代码和业务逻辑已经有一段时间了，例如，通过使用 web 服务连接到后端。在某些情况下，这是一个好主意，但无论如何都不是必需的，但会使您的架构、部署、设计和成本性能显着复杂化。

于 2008-09-25T16:47:31.760 回答
0

我发现 2.5 层设计最适合我创建的新 Web 应用程序。我通常从 2 个类库和 1 个 Web 应用程序开始。

  • Company.Data（类库）
  • Company.Web（类库）（包含PageBase、自定义控件、帮助函数等）
  • Company.Web.WebApplication（Web应用程序）

对于我创建的应用程序，我只使用存储过程来访问数据。事实上，我已经创建了 CodeSmith 模板来生成所有的存储过程、数据和业务类。

Company.Data

该程序集主要由实体数据类和集合组成。例如，我通常Settings在我的 Web 应用程序中调用一个表。一个名为Setting并将SettingCollection生成的类。

因此，如果我需要加载特定设置，我可以这样做..

Dim setting As New Setting(1) 'pass in the id of the specific setting
setting.Value = "False" 'change the value
setting.Save() ' Call the save method to persist changes back to the database

或创建一个新设置，我只是不在构造函数中传递值

Dim setting as New Setting()
setting.Name = "SmtpServer"
setting.Value = "localhost"

setting.Save()

我在Company.Data程序集中的命名空间通常看起来像这样..

Company.Data.Entites
Company.Data.Collections
Company.Data.BusinessObjects

（此命名空间用于创建访问数据的自定义方法）

我还根据主键、外键和唯一索引生成自定义方法。

例如，设置表中的名称列具有唯一索引。GetSettingByName将自动生成一个调用的共享方法 ，这将返回一个设置对象。此方法将在Company.Data.BusinessObjects命名空间中

对于实体和业务对象类，会生成两个文件。1 是每次生成的，1 是可编辑的并且只在第一次生成。我使用部分类来允许我添加自定义代码而不会被覆盖。

对我来说，这种方法非常有效。Codesmith 生成为我节省了无数小时的编码时间。我可以在一个表中添加 5 个新列，在几秒钟内重新生成所有新代码。存储过程将被删除并重新创建。

2.5 层设计效果很好，因为我的应用程序只使用一个数据库，那就是 Sql Server。以后不会再需要用到access、oracle、mysql了。

于 2009-12-30T15:14:58.440 回答
0

n层设计

我认为分层效果很好。 看看 OSI 模型中的层。 我已经使用了您描述的三层，这种方法确实很有帮助。模型视图控制器的抽象通常在大型桌面应用程序中很有帮助。您可以继续将事物分解成越来越小的更易于管理的部分。有一个收益递减点。并且，有时我们想要移除抽象层并可能直接与硬件对话——这取决于您的应用程序的目标。

于 2008-09-25T16:22:54.927 回答
-1

我们使用大约 6 层设计。

  • 浏览器端 Javascript 等等。这是纯粹的视觉糖，几乎没有商业价值或加工。这里的任何输入验证都是多余的检查——它们可以被绕过，所以我们不信任它们。

  • 服务器端 HTML 演示文稿。这部分是由业务规则驱动的。但是我们使用的模板语言没有处理。

  • 服务器端视图函数，业务逻辑，“控制”。这是导航、验证和“更高级别”的面向应用程序处理发生的地方。这是发生状态变化的地方——计算、更新、删除等等。这就是处理。这是强制执行身份验证和授权的地方。

  • 模型定义（使用 ORM 层）。这是对象模型。它映射到关系模型。它包括作为对象方法的所有模型级处理。这是完成一些计算的地方，过滤、计数、排序都在这里定义。这是我们有用的数据视图。

  • 访问层（某种数据库连接）。取决于数据库产品。它由 ORM 层管理，所以我们不做任何编码，只是配置。

  • 数据库中的持久存储（无存储过程，无触发器）。

于 2008-09-26T02:09:04.157 回答
-4

我们曾经使用以下方法来处理它： - UI 层（所有 UI 所在的位置） - 业务层（所有业务逻辑所在的位置） - 数据层（所有 DB 访问所在的位置）

于 2008-09-25T16:12:17.277 回答