对于有便携式区域经验的人，
我想知道使用它们是否有缺点以及为什么不会使用它们将大型MVC应用程序分解为组件部分。
答案 0 :(得分：12)
让我们从
开始<强>定义：
Portable Area是包含items的dll，通常是您解决方案的一部分。可移植区域包含视图，控制器，模型，甚至JS脚本，CSS文件和图像。
理想情况下，便携式区域中的items可以协同工作以创建内聚功能。如果没有，你可能不会从拥有便携式区域中受益。
<强>效益
我将便携式区域与网络表格Web Parts进行比较，因为他们都试图回答这个问题：
如何创建可重复使用的功能？
如果您想要创建在多个项目中使用的功能，或者作为第三方消费的功能分发，您将受益于可移植区域。
<强>缺点
每次对便携式区域内的任何视图，JS文件，CSS文件或图像进行更改时，都需要重建它。我强调这些组件，因为它们通常不需要在测试或开发时重建。
这可能会成为一个问题。如果您每次调整CSS时发现自己重新构建，则30秒更改将变为2分钟更改。制作其中的30个，你将工作时间延长到2个小时。
便携式区域意味着成熟的功能可以在多个项目或解决方案中重复使用。
便携式区域不适合处于早期开发阶段的功能。
便携式区域不适用于仅存在于一个解决方案或项目中的功能。
答案 1 :(得分：9)
很多事情已经说过了。我在使用便携式区域方面有一些经验，这是我的个人观点。
MvcContrib自一年后未更新（请参阅nuget）。如果您查看codeplex，您会发现自上一版本以来源代码中没有太多更新。它可能是成熟的，但没有任何支持可能会有问题。
便携式区域自包含在单个程序集中。它更容易重用和升级，但挑战在于如何让客户端应用程序对用户界面进行足够的控制。即使它是可重用的功能，您有时仍希望使用主布局或部分。
所有网络资源（CSS，Js，视图）都必须是嵌入资源（包含在dll中）。这意味着开发/调试真的很痛苦，因为每次代码修改都需要重建。此外，您需要客户端网站来托管便携式区域。
便携式区域使用自定义虚拟路径提供程序。自定义虚拟路径提供程序代码未经测试且完全不可测试。 ASP.Net团队不鼓励使用虚拟路径提供程序，因为它们可能会导致性能问题。
便携式区域与Nuget包。便携式区域是在四年前（Nuget之前）设计的.Portable Areas解决了将传输，查看和资产（Css，javacript）文件轻松传输到单独应用程序的能力。 Nuget也解决了这个问题。
然而，即使存在所有这些缺点，我的团队仍在使用它。为什么？因为在适当的时候这对我们来说是正确的解决方案。