采用点网技术的N层架构

Question

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

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

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

感谢您的最终答案。

Answer 1

您的架构应由您的受众决定。如果您拥有非常多的受众（按每个时段的请求进行衡量），那么您可能需要一种分布式架构，其利用Web服务的方式与您所描述的类似。但是，如果您的受众群体很小，那么您所描述的方法非常难以理解。

但是，如果您需要更新基础DLL但不希望每次都重新部署网站，那么有一个参数可以保留您当前的体系结构。在您当前的设置中，您每次都只是重新部署Web服务，而网站将不受影响。但是，除非您拥有一个非常活跃的网站，否则在您的DLL更改时重新部署网站可能无关紧要。

Answer 2

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

很多人花了很多时间担心他们是否有足够/太多的层次，不幸的是很多其他人花了很多时间试图解决其他人对他们的批评。

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

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

我并不是要暗示这些事情永远不会发生，他们肯定会这样做，但对于许多业务领域的很多开发人员而言，他们的发生并不像理论会让你相信的那么多。

很多这样的东西只是归结为如果没有重写应用程序的其他部分而无法实际看到替换的内容。剩下的就是试图猜测你从精心设计到过早优化的过程。

恕我直言 - 对于单独的序列化和编码处罚，如果他们总是要在同一台服务器上运行，我绝不会在网络应用上编写UI。如果您最初在理论上需要在其他地方扩展服务，我可以理解其动机，但是还有一些其他问题，如缓存数据到期和事务，如果所有事情<，那么这通常会导致这仍然是一个尴尬的选择/ em>真的必须运行WCF服务。它将您需要更改的内容增加三倍以添加字段，并使您从使用关系数据库的许多功能中脱离出来。

修改

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