采用点网技术的 N 层架构答案

【问题标题】：N-tiers architecture with dot net technologies采用点网技术的 N 层架构
【发布时间】：2012-06-27 00:41:14
【问题描述】：

我在网上看到过 n 层解决方案，它们都为每一层使用 DLL。我们的架构看起来相同：3 个 DLL：数据层、业务逻辑层和业务对象层。但是，表示层并不直接与这些层通信，而是通过 WCF Web 服务访问它们。

我们的 ASP.NET MVC 与 WCF WebService 托管在同一台机器上。

这是一个好的架构吗？如果 ASP.NET MVC 直接访问其他层会更合乎逻辑吗？

感谢您最终的回答。

【问题讨论】：

标签： .net asp.net-mvc architecture tiers

【解决方案1】：

层级分割线的正确数量在很大程度上取决于诸如网站遵循数据模型的紧密程度以及最终将在数据库上完成多少繁重工作。所以很难回答。

很多人花很多时间担心他们是否有足够/太多的层级，不幸的是，很多其他人花费大量时间试图绕过其他人规定的层级。

要真正回答这个问题，你需要考虑一些事情

您的应用现在的规模（您有 5 个用户还是 50,000 个用户）
您的应用程序的扩展（在升级之前您有多大可能达到 5,000,000 名用户）
在不重写的情况下您可能完全消化应用程序的整个部分的频率（即 - 我们已经完全改变了业务规则，但奇迹般地，只要您能做相反的事情，UI 仍然是正确的这个界面后面的东西）
您真正彻底改变存储或数据库基础设施的频率（作为 .net 开发人员，我没有去过很多一天刚醒来并决定切换 DMBS 的商店，但我有很多的经理坚持使用抽象层“以防万一”，而不是使用 linq2sql 或 EF）
您的某一层是否包含一些本质上很痛苦的东西，这些东西确实应该是带外 Web ui 资源的（处理图像或办公文档是转移到服务的两个很好的例子，只是为了隔离开销/不稳定性有时）

我并不是要暗示这些事情永远不会发生，它们肯定会发生，但对于许多业务线的许多开发人员来说，它们并没有像理论让你相信的那样发生。

很多这样的东西归根结底是为了不将你无法实际看到的东西替换掉而不重写应用程序的其他部分。剩下的就是尝试猜测从精心设计到过早优化的界限。

恕我直言 - 仅就序列化和编码惩罚而言，如果 Web 应用程序总是在同一台服务器上运行，我永远不会在 Web 应用程序上编写 UI。如果您最初这样做是因为理论上需要稍后在其他地方扩展服务，我可以理解其动机，但还有一些其他问题，例如缓存数据过期和事务，如果 everything 确实必须通过 WCF 服务运行。它使添加字段所需更改的内容数量增加了三倍，并使您无法使用关系数据库的许多功能。

编辑

OP 评论说 WCF 服务位于多个前端之后，因此该服务并不总是有效地与 UI 位于同一主机上。如果您要向 mvc 应用程序添加数据选项以返回 JsonResults 或其他内容，您仍然可以选择使用 MVC 返回其余端点并保持主 Web UI 完全连接到后端

【讨论】：

【解决方案2】：

您的架构应该由您的受众决定。如果您有非常多的受众（以每个周期的请求数衡量），那么您可能需要一种分布式架构，该架构以与您描述的方式类似的方式利用 Web 服务。但是，如果您的受众很少，那么您所描述的方法就非常过分了。

但是，如果您需要更新底层 DLL，但又不想每次都重新部署您的网站，则需要保留当前架构。在您当前的设置中，您只需每次重新部署 Web 服务，而网站不会受到影响。但是，除非您有一个非常活跃的网站，否则在您的 DLL 更改时重新部署该网站可能并不重要。

【讨论】：

你好 Brian，我忘了提到我们有不止一个表示层：移动设备（Android/iOS/BlackBerry）和 WPF/Java 富客户端，它们都访问 WCF Web 服务。我们认为以同样的方式对待 ASP.NET MVC 是合乎逻辑的。你怎么看？另外，回答您的问题：坦率地说，我们没有大量的观众。提前致谢。
哦，好吧，考虑到这一点，是的，您可能希望保留当前的架构。抱歉，您的原始帖子中没有明确说明。
最后一个问题，如果你允许我的话：如果我们在数据访问层和其他层之间放置一个 web 服务会很糟糕吗？
我并不是要回避回答你的问题，而是给你关于架构的一般建议。每当您考虑对架构进行更改时，请问问自己更改的真正好处是什么。如果好处证明改变是合理的，那就做出改变。如果您不能简明扼要地描述好处并用它们来证明架构的合理性，请不要这样做。哦，“XYZ 网站/应用程序使用这种架构”不是一个好处，只是要清楚。