Question

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

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

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

你如何接近它？

编辑：如果您要做的就是定义3层是什么，请不要浪费时间回复。我正在寻找特定的人如何实现它，你使用存储过程或ORM，你是如何处理DAL和BLL之间的循环依赖？除了说

之外，这个话题还有很多深度

UI
商业
数据

Answer 1

我一直在做一些主要的网络应用程序，并且一直关注3层：

UI：纯ASPX页面。实际上很难将你的业务层从这里推下来，因为快速计算或者其他东西在这里看起来很容易。但是，我已经足够自律，以确保页面后面的代码除了显示/隐藏面板，更新用户输入等之外什么都不做。

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

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

Answer 2

3层：

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

Answer 3

我练习3层设计的方式与我使用存储过程处理大部分（如果不是全部）与数据库的通信相同。我接近我的类的设计，以便每个类都有一个特定的目的，以降低复杂性，并在变更时提供更大的灵活性。

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

Answer 4

更多的旁注：永远不要忘记n层分层是逻辑分层，而不是进程的物理分离。即，不应该使业务逻辑在与表示代码不同的进程（或在不同的框中）上运行。重要的是保持代码清洁。

物理上分离表示代码和业务逻辑已经被宣传了一段时间，例如，通过使用webservices连接到后端。有些情况下这是一个好主意，但它没有任何必要，但会使您的架构，部署，设计和性价比大大增加。

Answer 5

n层设计

我认为分层效果非常好。 Take a look at the tiers in the OSI model.我使用了你所描述的三个层次，这种方法确实有帮助。模型视图控制器的抽象通常在大型桌面应用程序中很有用。您可以将事物分成更小，更小，更易于管理的部分。有一个收益递减点。并且，有时我们想要删除抽象层并且可能直接与硬件对话 - 这取决于应用程序的目标。

Answer 6

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

Company.Data（班级图书馆）
Company.Web（类库）（包含PageBase，自定义控件，辅助函数等）
Company.Web.WebApplication（网络应用程序）

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

Company.Data

此程序集主要由实体数据类和集合组成。例如，我的Web应用程序中通常有一个名为Settings的表。将生成一个名为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

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

我还基于主键，外键和唯一索引生成自定义方法。

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

中

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

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

2.5层设计运行良好，因为我的应用程序只使用一个数据库而且是Sql Server。将来不需要使用access，oracle，mysql。

Answer 7

我们使用大约6层设计。

浏览器端Javascript和什么不是。这是纯粹的视觉糖，几乎没有商业价值或加工。这里的任何输入验证都是冗余检查 - 它们可以被绕过，所以我们不相信它们。
服务器端HTML演示文稿。这部分是由业务规则驱动的。但是我们使用的模板语言没有处理。
服务器端视图功能，业务逻辑，“控制”。这是导航，验证和“更高级别”面向应用程序的处理的地方。这发生了状态变化 - 事物被计算，更新，删除等。这就是处理。这是强制执行身份验证和授权的地方。
模型定义（使用ORM层）。这是对象模型。它映射到关系模型。它包括作为对象方法的所有模型级处理。这是完成一些计算，过滤，计数，排序的地方。这是我们对数据的有用观点。
访问层（某种数据库连接）。取决于数据库产品。它由ORM层管理，因此我们不进行任何编码，只需配置。
DB中的持久存储（没有存储过程，没有触发器）。

Answer 8

DI为我取代了等级。是的，您仍然可以按层对逻辑进行排序，但逻辑层和数据库层之间的差异已经被其他设计问题所模糊，恕我直言。如果你不确定我的意思，请查看“贫血模型”战争。

Answer 9

我们曾经使用以下方法接近它： - UI层（所有UI都在） - 业务层（所有业务逻辑都在其中） - 数据层（所有数据库访问都在其中）

你们有多少人做3层设计？

9 个答案:

n层设计