我的架构是什么？答案

【问题标题】：What is my architecture?我的架构是什么？
【发布时间】：2012-02-09 13:23:33
【问题描述】：

我被要求定义我的应用程序的架构，但我对如何措辞感到有些困惑。大家觉得呢？

我们开发了一个 .Net MVC 应用程序。
在本地网络中使用。
我们有查看 MVC 网站（表示层）的工作站
我们有一个托管站点的应用程序服务器（逻辑层）
我们有一个存储数据的数据库服务器 (SQL 2008 R2)（数据层）

所以我认为由于层，它是一个三层架构。
但是，因为我们使用了 MVC，这是否意味着我们的层更直接（尽管松耦合）连接，从而使我们的架构线性度降低（三层）和三角形（MVC）？

你认为我应该如何描述这个架构？

【问题讨论】：

@user666262：您应该向技术人员或营销人员描述它吗？
MVC 表示层在 Web 服务器上运行，我猜你的逻辑也是如此，而托管站点的应用程序服务器就是 Web 服务器。在我看来，这是一个两层架构，web 和 db 后端。 MVC 是一个 UI 框架，不会添加或删除层。
为什么重要？该应用程序是否有效？它在现实世界的可用性测试中得分很高吗？源代码是否易于阅读、理解和维护？ 成功！随心所欲。
@CodyGray：它决定了向谁你需要解释它。例如，市场营销并不关心代码可读性、代码源控制等。他们可能对一些看板、演示或应用程序使用统计数据感兴趣。
营销通常也不关心设计模式。他们关心软件做什么。并且设计模式不做任何事情。

标签： c# model-view-controller architecture n-tier-architecture

【解决方案1】：

我认为“3 层架构”一词定义不明确且已过时，因为它没有突出代码的结构方式，也没有从用户的角度提供任何好处或缺点。问题在于它指的是物理部署，这在虚拟化和分布式计算时代几乎没有意义。

"Tier" refers to machines，并且由于您通常只能使用本地开发机器运行和调试您的网站，因此通常可以将其部署为 1 层。更相关的问题可能是“我可以将我的应用程序拆分成的（逻辑）机器的最大数量是多少？”这个数字与实际部署无关, 而是由代码的结构决定 - 由分层决定。当然，复制另一台机器的机器（用于负载平衡的多个 Web 服务器）不算在内。

这些信息仍然几乎不相关。它表明您的代码将关注点分开，并且可能比不允许拆分到单独层的代码更具可扩展性。另一个想法是强解耦：您可以更换一层而不接触另一层。在实践中，这几乎是行不通的（例如从 Oracle 切换到 MySQL），并且解决了一些过时的问题：“表示层中操作系统的更改只会影响用户界面代码。” (Wikipedia)

当您添加外部 SaaS/PaaS 产品或 SolR（搜索引擎）等第三方工具时，所有这些都变得更加模糊。 SolR 是数据层的一部分还是逻辑层的一部分？您的架构是否通过添加缓存层变成 4 层？如果您的数据库层不是一台机器，而是由 10 台机器组成的集群怎么办？

另一方面，MVC 指的是代码的结构方式。然而，这不仅仅是一种表示层模式：模型不知道控制器，也不知道视图。 MVC 将数据、表示和逻辑分成不同的层。大多数 MVC 实现使用Two-Step-View 作为表示层模式，PageController 作为控制器模式。 FrontController 通常也存在，并在委派给相应的 PageController 之前处理所有请求 - 但关键是模型并不知道所有这些。

我建议完全放弃“n 层架构”的概念。

【讨论】：

【解决方案2】：

我会将其描述为 3 层应用程序，并将 MVC 方面放入表示层。

由于您的基本结构是基于三层的结构，并且使用 MVC 向用户显示数据。（也许你可以把带有 MVC 的盒子覆盖在表现层和应用层——来说明这两者之间的实际交互）。

【讨论】：