问题标签 [3-tier]

服务层是不是外层？如果不是，那么它属于哪一层？

请回复

谢谢

假设我有一个 3 层架构（UI、业务和数据）。通常，我会创建一个名为“Model”或“Common”的第四个项目来保存我的数据访问对象，然后其他每个项目都会使用这个项目。

现在我正在开发一个项目，其中我的一些数据访问对象具有 Save() 等需要访问 Data 项目的方法。因此，如果我尝试在 Data 项目中使用 Model/Common 项目，我会有一个循环引用。

在这种情况下，保存数据访问对象的最佳位置在哪里？我可以将它保存在 Data 项目本身中，但是我的 UI 项目需要了解数据访问对象，需要访问 Data 层，这不好。

我正在构建标准的 3 层 ASP.NET Web 应用程序，但我正在为在哪里做某些事情而苦苦挣扎——特别是处理异常。

我试图在网上浏览一些示例，但找不到任何可以显示所有内容如何链接在一起的整个项目。

在我的数据层中，我连接到 SQL Server 并做一些事情。我知道我需要捕获可能因此引发的异常，但我不确定在哪里做。

从我读过的内容来看，我应该在 UI 层中执行此操作，但在这种情况下，我不确定如何确保与数据库的连接已关闭。有没有人能够澄清如何做到这一点？此外，如果有人知道我在哪里可以找到遵循最佳实践的示例 3 层 Web 应用程序，那也很棒。

谢谢

我有一个 3 层设计。(UI / BLL / DAL)

UI = ASP.NET MVC

在我看来，我收集了一个类别的产品。示例：产品 1、产品 2 等。

用户能够从视图中选择或删除（通过选中复选框）产品，最终在用户提交这些更改时保存为集合。

有了这个 3 层设计，这个产品集合将如何保存？如何过滤产品（删除和添加）到类别对象？

这是我的选择。

(A) 这是控制器的责任，那么伪代码将是

1. 查找用户选择或删除的产品，并与现有记录进行比较。
2. 将该集合添加或删除到类别对象。
3. 调用 SaveCategory(category); // 呼叫

这里前 2 个过程步骤发生在控制器中。

(B) 这是 BLL 的责任，那么伪代码将是

1. 收集用户选择的产品
2. SaveCategory（类别，产品）；// 呼叫

在这里，由 SaveCategory (BLL) 决定应该删除哪些产品并将其添加到数据库中。

谢谢

我正在构建一个传统的 .NET MVC 站点，所以我有一个自然的 3 层软件架构设置（以视图的形式呈现，控制器中的业务层以及模型和数据访问层中的数据层）。

当我部署此类站点时，它通常在一台服务器（网站和数据库所在的位置）或两台服务器（一个 Web 服务器和一个单独的数据库服务器）上运行。

如何实现 3 服务器架构（WEB、APP 和 DB）？Web 服务器是否只有演示文稿（例如物理视图/aspx 页面），应用程序服务器将保存配置文件和 bin 文件夹，而 db 服务器将保持原样？

我的问题本质上是，您可以简单地将 /bin 和所有应用程序逻辑从演示视图移到单独的服务器上吗？如果是这样，您如何配置服务器以知道在哪里查找？如果某处有一本好的入门书，或者有人可以告诉我内幕，我将永远感激不尽。

我试图制作我的第一个 3 层应用程序。在此过程中，我遇到了一个尚未找到最佳解决方案的问题。基本上我所有的对象都使用一个 IFillable 接口，它强制实现一个子，如下所示

然后，这个 sub 期望来自 datareader 的 Id 将与对象的属性相同。

最后，我最终得到了一个看起来像这样的数据层。

大多数情况下，这种模式似乎是有道理的。但是我的问题是，假设我想为 Stock 实现一个名为 StockBarcodeList 的属性。在上述模式下，无论我以何种方式实现此属性，我都需要将连接字符串传递给它，这显然会破坏我对层分离的尝试。

有没有人对我如何解决这个问题有任何建议，或者我是否以完全错误的方式解决这个问题？有人对我如何改进我的实施有任何建议吗？但是请注意，我故意避免以任何形式使用数据集。

我对表达 3 层架构的不同可能性感到困惑。

或者

为什么可以在第一种方法中跳过数据库？两者都使用数据库！数据库是否属于分层？！

什么是错的，什么是对的？

你们有人可以澄清一下吗？

我实际上被困在三层结构中。我在网上冲浪，发现了两个术语“数据库抽象层”和“数据访问层”。

两者有什么区别？

在 MVC 和 3 层或 N 层架构中开发网站有什么区别？

哪一个更好？有什么优点和缺点？

它可能是一个简单的 3 层问题。我只是想确保我们为此使用最佳实践，而且我对这些结构还不是很熟悉。

我们有 3 层：

• GUI：用于表示层的 ASP.NET（第一个平台）
• BAL：业务层将在 C# 中处理网络服务器上的逻辑，所以我们都可以将它用于 webforms/MVC + webservices
• DAL：数据层中的 LINQ to SQL，返回 BusinessObjects 而不是 LINQ。
• DB：SQL 将是 Microsoft SQL-server/Express（尚未决定）。

让我们考虑一下我们有一个 [Persons] 数据库的设置。他们都可以有多个 [Address] 并且我们有所有 [PostalCode] 和相应城市名称等的完整列表。

交易是我们从其他表格中加入了很多细节。

{关系}/[表格]

• [Person]:1 --- N:{PersonAddress}:M --- 1:[Address]
• [地址]:N --- 1:[邮编]

现在我们要为 Person 构建 DAL。PersonBO 的外观应该如何以及连接何时发生？获取所有城市名称和可能的地址公关是业务层问题吗？人？或者 DAL 是否应该在将 PersonBO 返回给 BAL 之前完成所有这些？

// Q1：我们在返回 PersonBO 之前检索对象吗？它应该是一个数组吗？或者这对于 n 层/3 层来说是完全错误的吗？

// Q2：我们是进行查找还是留下 PostalCode 以供以后查找？

谁能解释以什么顺序拉哪些对象？建设性的批评是非常受欢迎的。:o)