辅助方法来生成HTML的小片段 [英] Helper methods to generate small HTML snippets

查看:161
本文介绍了辅助方法来生成HTML的小片段的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我使用ASP.NET MVC从我的模型分开我的HTML视图。但是还有就是困惑我稍微具体情况。

我的信息的几个常用的小板,这本身是由许多小的信息面板中。这些获得包含的各种模型内的子类的数据,有时单的情况下,有时对象列表。

在present这是使用局部的意见完成后,通过模型参数传递适当的数据块,因此:

  @ Html.Partial(的UserInfo,this.Model.CurrentUser);
@ Html.Partial(的UserInfo,reply.PostedBy);

等。这一切工作正常。

我最近打感觉就像它绵延但是这种模式合理限度的要求 - 它会涉及到非常多的使用HTML的一个很小的量在每一个嵌套的无数次局部视图。该网页解决时间似乎开始变得有点失控,我怀疑搜索和反映局部视图可能有一些用它做的量。

请注意:的我假设重复这应该是相同的HTML仍然是要避免的。我可以通过在某些更高级别的控制HTML的副本简化鸟巢,但是这让我这个损失可维护性。

有关最内层的人就似乎更有意义,我要创建的生成静态辅助类,并返回所需的HTML - 但是,尽管MVC本身并没有将其与 HTML 辅助类,感觉就像这违背了MVC模式。


  • 是否确定使用静态辅助类来生成小的HTML片段?

  • 静态的UserInfo 类应该去哪里?看法?控制器?在其他地方?

显然,这种方法仍然分离模型辅助方法,但因为它需要一个模型的工作,我实在不明白它确实是多么耦合。

一个静态的助手是从头发的扩展方法广度远,消耗在 userInstance.InfoHtml()类型的方式,这似乎只是使整个做法真的类似于只需添加辅助方法模型。当然,这是什么MVC正试图从摆在首位跑不掉的!

请注意:的我并不想偷偷摸摸的规则或抱怨!我只是想办法这是关于模式成为可能。如果很多很多的部分景色是这样的,我也有和性能调整坚持,尽我所能。


解决方案

我相信有四种常见的解决方案,你的问题要重复使用的HTML。


  1. 部分视图( @ Html.Partial );

  2. 儿童行动( @ Html.Action );

  3. 自定义静态佣工( @ Html.Whatever @ Url.Whatever ,扩展方法,你的模型等);

  4. 剃刀帮手。 ( @helper


  

它是确定以使用静态辅助类来生成小的HTML片段?


它是绝对OK使用静态辅助类来生成HTML的小片段。我不喜欢这个主意,将其添加为方法,以模型,扩展方法都行。

我想说的方法之间的差异主要取决于编码风格和个人preferences。我会使用局部视图只是为了打破一个大的视图成耗材件,为应用程序(如Widget或登录框)的真正的共同和独立的部分孩子的行为,所以我没有来用我所有的视图模型常见的事情的数据。我会去静态佣工或剃刀助手对非常小的HTML片段(在表单中字段)更多code和剃刀帮手更多的HTML静态帮手。


  

应该在哪里静态的UserInfo类去了?看法?控制器?在其他地方?


这些东西都属于从模式的角度来看待。如果你问你应该在解决方案中填充的文件夹,我会建议一个特殊的文件夹为他们(也许 HtmlHelpers )。有可能是共享剃须刀佣工居住在 APP_ code 文件夹的限制。

我认为以下几个问题会给你更多关于如何在两者之间选择:


  1. Creating在ASP.NET MVC 使用可重复使用的剃刀HTML视图组件;

  2. 如何在ASP.NET MVC创建可重用的控制;

  3. How创建可重用一块HTML的动态内容;

  4. ASP.NET MVC:剃刀@helper VS扩展方法的HtmlHelper - 这是preferred

更新

有可能会在新的ASP.NET MVC第五个解决方案:的视图组件。至于我念你可以使用它们替代孩子的行动。

I'm using ASP.NET MVC to separate my HTML views from my Models. However there's a specific situation that is confusing me slightly.

I have several commonly used small panels of information, which themselves are comprised of a number of smaller panels of information. these get their data from a subclass contained within the various models, sometimes single instances, sometimes lists of objects.

At present this is done using Partial views, passing the appropriate piece of data via the model parameter, as such:

@Html.Partial("UserInfo", this.Model.CurrentUser);
@Html.Partial("UserInfo", reply.PostedBy);

And so on. This all works fine.

I've recently hit a requirement which feels like it stretches sensible limits for this model however - it will involve a very large number of partial views with a TINY amount of HTML in each, nested numerous times. The page resolution time seems to be starting to get a little out of hand, and I suspect the amount of searching for and reflecting partial views might have something to do with it.

Please note: I'm assuming duplicating HTML which is supposed to be the same is still to be avoided. I could simplify the nest by having copies of HTML in some of the higher level controls, but it strikes me this damages maintainability.

For the inner most ones it would seem to make more sense to me to create static helper classes which generate and return the required HTML - however, despite the fact MVC itself does it with the Html helper class, it feels like this goes against the MVC pattern.

  • Is it OK to use static helper classes to generate small HTML snippets?
  • Where should the static UserInfo class go? Views? Controllers? Elsewhere?

Obviously this approach still separates the helper method from the model, but as it takes a model in to work with, I don't really see how uncoupled it really is.

A static helper is a hairs breadth away from an extension method, consumable in a userInstance.InfoHtml() type of way, which just seems to make the whole approach really similar to just adding the helper method to the model. This is of course what MVC is trying to get away from in the first place!

Please note: I'm not trying to sneak around the rules or complain! I just want to approach this as "on pattern" as possible. If lots and lots of partial views is the way, I'll stick with that and performance tune as best I can.

解决方案

I believe there are four common solutions to reuse html as you want in the question.

  1. Partial views (@Html.Partial);
  2. Child Actions (@Html.Action);
  3. Custom static helpers (@Html.Whatever, @Url.Whatever, extension methods to your models, etc);
  4. Razor helpers. (@helper)

Is it OK to use static helper classes to generate small HTML snippets?

Is it absolutely OK to use static helper classes to generate small HTML snippets. I don't like the idea to add them as methods to the models, extension methods are OK.

I would say the difference between the approaches lies mostly in coding style and personal preferences. I would use partial views just to break a large view into consumable pieces, child actions for really common and independent parts of the application (like a widget or a login box), so I don't have to populate all my view models with the data for common things. I would go static helpers or razor helpers for very small html fragments (a field in a form) with static helpers for more code and razor helpers for more html.

Where should the static UserInfo class go? Views? Controllers? Elsewhere?

These things belong to View from the pattern perspective. If you ask which folders should you populate in the solution, I would recommend a special folder for them (maybe HtmlHelpers). There is probably a restriction for shared razor helpers to reside in App_Code folder.

I think the following questions will give you more on how to choose between them:

  1. Creating reusable HTML view components using Razor in ASP.NET MVC;
  2. How to create reusable control in ASP.NET MVC;
  3. How to create a reusable piece of HTML with dynamic contents;
  4. ASP.NET MVC: Razor @helper vs extension methods to HtmlHelper - which is preferred?.

UPDATE

There may be a fifth solution in the new ASP.NET MVC: View Components. As far as I read you can use them instead of child actions.

这篇关于辅助方法来生成HTML的小片段的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆