问题标签 [multi-tier]

我有一个执行许多定期活动的 Windows 服务，我想从 Windows 窗体应用程序更改此服务的设置。不过，我不确定确保服务中包含最新用户首选项的最佳方法（运行频率、用于事物的文件夹、用户可以指定的任何其他内容）。用户可以随时随意更改设置，我希望服务几乎立即知道它。以下是我正在权衡的选项：

1. 表单和服务共享使用来自第三个共享项目的相同“设置”对象，并且表单使用 WCF“UpdateSettings(newSettings)”调用让服务知道发生了更改（或者，可以选择调用更新每个单独的设置，尽管这在不同的调用中似乎很多）。我目前将 WCF 用于基本消息，但设置对象可能很大，因为那里有很多其他的东西
2. 表单和服务使用一个通用的配置文件（XML，或来自 #1 的相同设置对象，但序列化到磁盘）。表单只是在对象被更改后写入对象的新副本，服务会不时检查并拾取它，如果它是新的，则更新其设置副本
3. 与 #2 相同，但有一个基本的 WCF 调用，告诉服务去获取设置。本质上，是#2 的“按需”而不是“轮询”版本。

我知道最好是主观的，但我对这些选择的任何明显的利弊原因感兴趣。由于我必须在应用程序运行（重新启动等）之间保存我的设置，所以无论如何我都必须将设置序列化到磁盘，所以我已经倾向于#2 或#3。我需要一个可以保存设置的磁盘位置，但也许 AppData 文件夹可以正常工作，尽管这只允许管理员更改设置，因为他们是唯一有权写入此位置的人（每个用户，包括服务帐户，都可以阅读它）。

感谢您的洞察力！

我对架构非常陌生，我正在为我的下一个 .NET 项目设计一个应用程序。我提出的架构设计如下：

它是传统的三层应用程序，其中包含： DataLayer (LINQ + Partial Classes) BusinessLogicLayer (Entities + Validation Logic) (Optional) Service Layer (WCF) UI (Web site and Windows App)

数据层：数据层将包含我的 DataContext 类（即 LINQ）和部分类。这些部分类将具有基本的计算逻辑（例如 Calc. VAT）和其他数据库级别的验证逻辑。

业务层：这将具有类似于数据层的实体，但也将包含 UI 级别的验证逻辑。例如，如果用户尝试输入数据库中不存在的用户名，则需要告诉用户该用户不存在。（这是我苦苦挣扎的地方）。每当调用属性而不是创建对象时，都会延迟加载对象。

UI：这将是一个传统的 UI 层，将在其中调用业务实体。

即使在使用 LINQ 时，我也将业务层从 DataLayer 中分离出来的原因是，如果我希望为例如 WCF 服务添加更多中间层实体，那么我希望它与业务层而不是数据交谈。我相信当应用程序增长时，解耦会有所帮助。（我认为）

如果有人可以对上述内容发表评论，我会很高兴。我真正的问题是编写业务课程（显然）。例如，在延迟加载中，当我尝试加载对象并且数据库中没有数据时，我希望我的 UI 向用户显示该用户不存在（如果我正在搜索用户名）。您对此有何建议。对此的任何输入都非常受欢迎。

非常感谢， Preyash

多层和/或分布式应用程序，它们是否具有相同的含义？

当我们谈论这些应用程序中的层时，是物理层（数据库、浏览器、Web 服务器……）还是逻辑层（数据访问层、业务层……）？

第 19 章：MSDN 上的物理层和部署描述了“分布式部署”（见图 2）。一切都很好。

根据我的经验，我们总是按照他们所说的“非分布式部署”（图 1）来部署基于 Web 的系统。我的理解是，在 Microsoft 世界中，作为独立事物的“应用程序服务器”并不真正存在（就像在 Java 世界中那样），因为它有效地“融入”了操作系统/Windows。

所以我的问题是，如果您要将 UI 和业务逻辑 (BL) 分发到不同的服务器/层，它们将如何通信？

我知道一个答案是使用“服务层” - 有哪些替代方案？你会怎么做呢？从代码的角度来看它会是什么样子？

我在 c# 中有一个多层应用程序，它应该在数据库上执行任务（如果第一次使用，我们可能会创建数据库并用一些数据填充它）。当我最初设计应用程序时，我没有考虑可能的进度条控件，更不用说任何形式的进度报告了。如何修改应用程序的设计以便能够向 UI 层报告数据库操作进度？是否有一个可重复使用的解决方案，并且不会强迫我修改我的所有功能以获取额外的报告输入？

我正在设计一个新网站的架构。由于多层架构肯定具有过早优化的所有症状（复杂性、开发时间等），我很想在这一点上避免它，但是，我相信在编写系统之后引入这样的架构（并引入它正确）将非常昂贵。我确实相信，如果网站变得足够大，那么这样的架构势在必行。

你怎么看？

在我们的应用程序中，我们有不同的层。服务层、DAO 层和操作（struts 应用程序）。

数据从一层传递到另一层。

理想情况下我们应该把输入验证放在哪里？

比如说，用户 ID、电话号码来自 UI，它们是强制性的。所以我们已经在客户端进行验证。

现在，根据我的观点，这就是你所需要的。没有其他地方应该验证它。

但是我的一位同事争辩说，如果客户直接提出要求怎么办。所以我们还需要添加Actions。

现在，在 Dao 中，同样的方法也被用于其他一些操作，并且没有验证，

或者，说服务层，它可能被暴露为，比如 web 服务，所以你也有验证。

所以本质上，他是在建议..我们到处都有验证。这对我来说没有意义。它的跨层重复。

什么是理想的方法？说验证可能是简单的空检查或一些复杂的验证。

为了在最近的课程作业中获得最高分，我被要求使用 c++ 和多层编程开发一个特定的应用程序。

我了解多层架构背后的理论，以及该应用程序的哪些部分属于哪一层，但我没有实际实现“n 层”应用程序的经验。

层必须完全分开吗？例如，一个进程运行数据库，一个进程运行 UI，第三个进程管理两者之间的交互？

还是就像将应用程序分成代码层一样简单，这样 GUI 就不会直接访问数据库等。

您对 C++ 中的多层编程的任何提示将不胜感激:)

我已经为一个客户编写了一个会员网站，其中的会员在其他用户的下方加入。例如

约翰和吉尔在顶部，乔和胡安在约翰之下，珍妮特和乔治在乔之下。分层用于传递佣金。我的客户希望能够查看在任何给定用户之下有多少用户，（至少它被限制为 8 层）

现在我已经将附加字段“num_below”添加到用户表中，每当有人加入或离开用户下方时，该字段就会递增或递减。

这样做的第一个问题是感觉它违反了良好的数据库规范化实践~因为它存储了已经在数据库中的数据

第二个是当我的客户过来说“哦，乔治打算加入胡安的手下，请移动他”时，它变得毛茸茸的

我考虑只是在每次被要求时动态计算下面的数字，但数据库查询似乎呈指数增长。

我写了一个rectifySubs()函数，可以遍历并修复所有的`num_below`字段，但是随着成员越来越多，运行起来会越来越密集~

有什么建议吗？我不想在数据库中放置过多的冗余数据，但每次执行 8 层似乎太占用处理器资源了。

- 编辑 -

我不太清楚这些层是如何工作的，所以我把桌子做得更大了。我在编辑中解决的关键问题是，任何人都可以在其正下方的一层中拥有多个人。希望这是有道理的。

-- SOLUTION -- (将 Kakao 的解决方案作为 'Member' 类的方法实现)

通常，当应用程序部署在服务器场上时，它有一个中央数据库、一个或多个应用程序服务器以及一个或多个 Web 服务器。

既然应用层中的所有服务都将通过 Web 服务器访问，那么为什么不将 Web 服务器部署在与应用服务器相同的物理层上呢？

具体查询是 - 将 Web 服务器部署为单独层的原因是什么？

从更广泛的角度来看，决定部署方案时的一般考虑因素是什么？