Asp.net 是否将助手类存储在单独的程序集中？

我只是想知道，是否有人将其助手类或方法存储在单独的程序集中，以及为什么……只是为了干净地管理它们？我看到过很多关于在MVC项目中使用helper文件夹的帖子，这让我回到了ASP.NET中混乱的旧时代，人们使用App_代码文件夹，而不是像这样在物理上将内容清晰地分离到自己的项目中

---

同样地，没有人做真正的体系结构，也不会把模型放在MVC web组件的某个文件夹中。它们可以放在MyApp.DataLayer assembly或MyApp.Models或类似的东西中。

我们在单独的项目中有一些助手，在web项目中也有一些助手。我认为您会发现一些助手需要使用您在web项目本身中定义的抽象。这通常会迫使您将这些助手放到web项目中，因为可能不希望有其他项目引用web项目。我不认为它与使用Appl代码一样。这些是在IDE内部编译时编译的文件，没有应用于App_代码的特殊“魔力”

我使用项目来分离web或表单应用程序中的不同层。这使我能够更好地遵守业务规则。此外，如果我想做出改变，我发现更容易找到我需要去的地方

---

但是我看到有人使用文件夹来标记解决方案中的层，但我认为这有点混乱。

是的，但原因是，这也是其他程序集所共有的

• 很容易插入任何其他项目。（可能需要一些版本）
• 可重复使用
• 易于改进
• 易折射
• 不是项目的一部分，而是项目的一部分 就其本身而言，它很容易记录，也很容易让开发人员理解
• 清除一些混乱

---

但是，对于以上所有内容，您的程序集在准备就绪时应该是一个“完成得很好”的工作。另一方面，最好将helper类保留在它们所属的位置。

是的，因为它们是业务层的一部分。两大好处：

• 可重用性
• 可测试性

---

请记住，实用程序函数和助手类可能是整个系统中使用最频繁的组件。如果没有完整的二头肌测试，您将面临无法接受的风险。

我创建的大多数助手通常是特定于层的，因此我倾向于将它们与需要它们的基本组件一起保存。我认为没有理由添加另一个项目来存储大量特定的助手类

我的意思和App_代码的意思不一样，我的意思是把应该放在单独程序集中的东西放在web应用程序的某个子文件夹中，我理解。我的第一个倾向是把它们也放在一个单独的组件中。但这是错误的。当我第一次需要制作一个使用web项目中的类的HTML帮助程序时，我意识到，至少在我的情况下，可能在许多情况下，帮助程序最好属于web项目。我或多或少地谈论的是那些只针对某个项目的帮助程序。我仍然认为从物理上把它们分开只会让发现事物变得更容易（发现能力）这是一种更专业的方式来维护和减少web应用程序中的混乱。并非您创建的所有帮助程序都可以在任何mvc项目中重用。您能否澄清一件事：您是否专门讨论HTML帮助程序扩展方法以及包含它们的类？或者您是在更广泛地讨论在构建应用程序的过程中创建的各种“助手类”吗？你的帖子说的是“helper类”，但也提到了“helper”文件夹，许多人在其中放置“HTML helper方法”（以及包含这些方法的静态类）。