使用.NET技术的N层架构

Question

使用.NET技术的N层架构

.netasp.net-mvcarchitecturetiers

3

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

我们的ASP.NET MVC托管在与WCF Web服务相同的机器上。

这是一个好的架构吗？如果ASP.NET MVC直接访问其他层，是否更合理？

感谢您的答复。

- Akli

2个回答

2

分层的正确划分数量会很大程度上取决于网站如何紧密地遵循数据模型以及数据库需要承担多少重负，因此很难回答。很多人花费了大量时间来担心他们是否有足够或过多的层级，不幸的是，很多其他人也花费了大量时间尝试绕过其他人所规定的层级。

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

- 应用程序现在的规模（您是否有5个用户还是50,000个用户） - 应用程序的扩展性（在升级之前，您有多大可能达到500万个用户） - 完全重写应用程序某个部分的频率（即 - 我们已经完全更改了业务规则，但奇迹般地，只要您可以在该界面后面执行相反的操作，UI仍将是正确的） - 你会现实地多频繁地完全改变你的存储或数据库基础设施吗？（作为一个.NET开发者，我参加的许多商店都没有突然醒来并决定切换DMBS，但我有很多经理坚持使用抽象层“以防万一”，这样就会花费数万小时的时间成本，而不是使用linq2sql或EF） - 是否有一个层包含一些本质上痛苦的东西，这些东西应该超出Web UI资源的范围（处理图像或Office文件是移动到服务中以隔离开销/不稳定性的两个好例子）。

很多时候，这些东西只是因为不要把一些你不能现实地看到替换而不重新编写应用程序的部分划分成一个层次。其余的就是试图猜测你何时跨越了从良好设计到过早优化的界限。

在我看来，仅仅由于序列化和编码惩罚，如果UI始终运行在同一台服务器上，我永远不会编写针对Web应用程序的UI。如果您最初是使用理论上需要扩展服务的需求进行此操作，我可以理解这种动机，但还有一些其他问题，例如缓存数据过期和事务经常出现，使得这仍然是一个笨拙的选择，如果 everything 确实必须通过WCF服务运行。它会使您需要更改的内容数量增加三倍，并且阻止您使用关系数据库的许多功能。

编辑：

OP发表评论说WCF服务位于多个前端之后，因此服务未始终在与UI相同的主机上。如果您将数据选项添加到MVC应用程序以返回JsonResults或类似内容，则仍可以使用MVC返回rest端点并使主Web UI完全连接到后端。

- Bill

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Brian Driscoll · Accepted Answer

您的架构应该根据您的受众来确定。如果您的受众非常大（以请求每个周期为衡量标准），那么您可能需要使用类似于您描述的方式利用 Web 服务的分布式架构。但是，如果您的受众很少，那么您描述的方法就非常过度了。

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