3

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

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

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

感谢您最终的回答。

4

2 回答 2

3

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

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

于 2012-06-25T18:08:21.860 回答
2

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

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

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

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

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

很多这些东西只是归结为不要在不重写应用程序的其他部分的情况下无法实际看到替换的东西中创建一个层。剩下的就是试图猜测你从精心设计到过早优化的界限在哪里。

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

编辑

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

于 2012-06-25T18:34:32.230 回答