我在网上看到了n层解决方案，它们都为每一层使用DLL . 我们的架构看起来是一样的：3个DLL：数据层，业务逻辑层和业务对象层 . 但是，表示层不直接与这些层通信，而是通过WCF Web服务访问它们 .
我们的ASP.NET MVC托管在与WCF WebService相同的机器上 .
这是一个很好的架构吗？如果ASP.NET MVC能够直接访问其他层，那会更合乎逻辑吗？
感谢您的最终答案 .
您的架构应由您的受众决定 . 如果您拥有非常多的受众（按每个时段的请求进行衡量），那么您可能需要一种分布式架构，其利用Web服务的方式与您所描述的类似 . 但是，如果您的 Spectator 很小，那么您所描述的方法非常难以理解 .
但是，如果您需要更新基础DLL但不希望每次都重新部署网站，那么就可以保留当前的体系结构 . 在您当前的设置中，您每次都只是重新部署Web服务，而网站将不受影响 . 但是，除非您拥有一个非常活跃的网站，否则在您的DLL更改时重新部署网站可能无关紧要 .
层的分界线的正确数量将在很大程度上取决于网站跟随数据模型的紧密程度以及最终将在数据库上完成的繁重程度 . 所以很难回答 .
如果他们有足够/太多的层次，很多人会花很多时间担心，不幸的是，很多其他人花了很多时间试图解决其他人对他们的决定 .
要真正回答这个问题，你需要考虑一些事情
您的应用程序现在的规模（您有5个用户或50,000个用户）
您的应用扩展（在您升级之前，您有多少可能获得5,000,000名用户）
你可以完全消除整个应用程序部分而无需重写的频率（即 - 我们已完全改变了业务规则，但是由于一些奇迹，UI仍然是正确的，只要你可以做相反的事情背后这个界面）
你实际上完全改变你的存储或数据库基础设施的频率（作为.net开发人员我没有去过很多商店，有一天刚刚醒来并决定转换DMBS，但我有很多经理坚持抽象等级"just in case"，随着时间的推移成本上花费数万，而不是使用linq2sql或EF）
你的其中一个层是否包含一些内在痛苦的东西，它应该是带外的web ui资源（处理图像或办公文档是移动到服务的两个很好的例子，只是为了隔离开销/不稳定性）
我并不是要暗示这些事情永远不会发生，他们肯定会这样做，但对于许多业务领域的很多开发人员而言，他们的发生并不像理论会让你相信的那么多 .
很多这样的东西只是归结为如果没有重写应用程序的其他部分而不能实际看到替换的东西 . 剩下的就是试图猜测你从精心设计到过早优化的过程 .
恕我直言 - 对于单独的序列化和编码处罚我永远不会在Web应用程序上编写UI，如果他们总是要在同一台服务器上运行 . 如果你最初这样做，理论上需要在其他地方扩展服务，我可以理解其动机，但还有一些其他问题，如缓存数据到期和交易，如果一切真的必须运行，通常会使这仍然是一个尴尬的选择通过WCF服务 . 它将您需要更改的内容增加三倍以添加字段，并使您从使用关系数据库的许多功能中脱离出来 .
edit
OP发表评论说WCF服务落后于几个前端，因此服务并不总是与UI有效地在同一主机上 . 如果您要将数据选项添加到mvc应用程序以返回JsonResults或其他内容，您仍然可以选择使用MVC返回其他 endpoints 并保持主Web UI完全连接到支持
2 回答
您的架构应由您的受众决定 . 如果您拥有非常多的受众（按每个时段的请求进行衡量），那么您可能需要一种分布式架构，其利用Web服务的方式与您所描述的类似 . 但是，如果您的 Spectator 很小，那么您所描述的方法非常难以理解 .
但是，如果您需要更新基础DLL但不希望每次都重新部署网站，那么就可以保留当前的体系结构 . 在您当前的设置中，您每次都只是重新部署Web服务，而网站将不受影响 . 但是，除非您拥有一个非常活跃的网站，否则在您的DLL更改时重新部署网站可能无关紧要 .
层的分界线的正确数量将在很大程度上取决于网站跟随数据模型的紧密程度以及最终将在数据库上完成的繁重程度 . 所以很难回答 .
如果他们有足够/太多的层次，很多人会花很多时间担心，不幸的是，很多其他人花了很多时间试图解决其他人对他们的决定 .
要真正回答这个问题，你需要考虑一些事情
您的应用程序现在的规模（您有5个用户或50,000个用户）
您的应用扩展（在您升级之前，您有多少可能获得5,000,000名用户）
你可以完全消除整个应用程序部分而无需重写的频率（即 - 我们已完全改变了业务规则，但是由于一些奇迹，UI仍然是正确的，只要你可以做相反的事情背后这个界面）
你实际上完全改变你的存储或数据库基础设施的频率（作为.net开发人员我没有去过很多商店，有一天刚刚醒来并决定转换DMBS，但我有很多经理坚持抽象等级"just in case"，随着时间的推移成本上花费数万，而不是使用linq2sql或EF）
你的其中一个层是否包含一些内在痛苦的东西，它应该是带外的web ui资源（处理图像或办公文档是移动到服务的两个很好的例子，只是为了隔离开销/不稳定性）
我并不是要暗示这些事情永远不会发生，他们肯定会这样做，但对于许多业务领域的很多开发人员而言，他们的发生并不像理论会让你相信的那么多 .
很多这样的东西只是归结为如果没有重写应用程序的其他部分而不能实际看到替换的东西 . 剩下的就是试图猜测你从精心设计到过早优化的过程 .
恕我直言 - 对于单独的序列化和编码处罚我永远不会在Web应用程序上编写UI，如果他们总是要在同一台服务器上运行 . 如果你最初这样做，理论上需要在其他地方扩展服务，我可以理解其动机，但还有一些其他问题，如缓存数据到期和交易，如果一切真的必须运行，通常会使这仍然是一个尴尬的选择通过WCF服务 . 它将您需要更改的内容增加三倍以添加字段，并使您从使用关系数据库的许多功能中脱离出来 .
edit
OP发表评论说WCF服务落后于几个前端，因此服务并不总是与UI有效地在同一主机上 . 如果您要将数据选项添加到mvc应用程序以返回JsonResults或其他内容，您仍然可以选择使用MVC返回其他 endpoints 并保持主Web UI完全连接到支持