我正在使用ASP.NET MVC将HTML视图与模型分开。但是，有一种特定的情况使我有些困惑。
我有几个常用的小型信息面板，它们本身由许多较小的信息面板组成。它们从各种模型（有时是单个实例，有时是对象列表）中包含的子类中获取数据。
目前，这是使用部分视图完成的，并通过模型参数传递了适当的数据，例如：
@Html.Partial("UserInfo", this.Model.CurrentUser);
@Html.Partial("UserInfo", reply.PostedBy);
等等。这一切都很好。
我最近遇到了一个需求，感觉像是它对该模型有一定的局限性-它将涉及大量局部视图，每个局部视图中都有少量的HTML，嵌套了无数次。页面解析时间似乎开始有点失控，我怀疑搜索和反映局部视图的数量可能与此有关。
请注意：我假设仍然应该避免重复相同的HTML。我可以通过在一些更高级别的控件中包含HTML副本来简化嵌套，但这使我感到不安，这损害了可维护性。
对于最内层的人来说，创建静态辅助类来生成并返回所需的HTML对我来说似乎更有意义-但是，尽管事实上MVC本身使用Html辅助类来完成，但感觉这与MVC模式背道而驰。
UserInfo类应该去哪里？意见？控制器？别处？显然，这种方法仍然将helper方法与模型分开，但是由于要使用模型，因此我并没有真正看到它是如何分离的。
静态帮助程序与扩展方法之间的距离很短userInstance.InfoHtml()，它可以以某种方式使用，这似乎使整个方法与将辅助方法添加到模型中非常相似。当然，这是MVC首先想要摆脱的！
请注意：我不是在偷偷摸摸的规则或抱怨！我只想尽可能以“按模式”进行处理。如果要使用很多局部视图，那么我将坚持并尽可能调整性能。
我相信，有四个常见的解决方案可以根据需要在HTML中重复使用html。
@Html.Partial）;@Html.Action）；@Html.Whatever，@Url.Whatever模型的扩展方法等）；@helper）是否可以使用静态帮助器类来生成小的HTML代码段？
使用静态帮助器类生成小的HTML代码段是否绝对可以。我不喜欢将它们作为方法添加到模型的想法，扩展方法还可以。
我想说这两种方法之间的差异主要在于编码风格和个人喜好。我将使用局部视图只是将一个大的视图分解为易用的部分，应用程序真正常见和独立部分（例如小部件或登录框）的子操作，因此我不必在所有视图模型中填充常见事物的数据。对于极小的html片段（表单中的字段），我将使用静态助手或剃刀助手，对于更多代码，将使用静态助手或对于更多html的剃刀助手。
静态UserInfo类应该放在哪里？意见？控制器？别处？
这些东西从模式角度来看属于View。如果您问应该在解决方案中填充哪些文件夹，我会为它们推荐一个特殊的文件夹（也许HtmlHelpers）。共享的剃刀助手在App_Code文件夹中可能存在限制。
我认为以下问题将为您提供更多有关如何选择它们的信息：
新的ASP.NET MVC中可能有第五种解决方案：查看组件。据我阅读，您可以使用它们代替子操作。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句