直积和笛卡尔积_ASP.NET，缓存和笛卡尔积

直积和笛卡尔积

I'm a HUGE believer in caching and unfolding data.  If you have a little extra RAM on your Web Servers, take advantage of it and cache.  When caching on the Web Server, the form of the data you cache should "look" as much like the data the end user would see.  In other words, if you have VERY normalized data in the database, but the HTML that will eventually be rendered to the user is a very unfolded, flat version of that data, then the data you cache should look more like the latter than the former.

我是缓存和展开数据的忠实信徒。 如果您的Web服务器上有一些额外的RAM，请利用它并进行缓存。 在Web服务器上进行缓存时，缓存的数据形式应“看起来”与最终用户将看到的数据一样。 换句话说，如果您的数据库中有非常标准化的数据，但是最终将呈现给用户HTML是该数据的非常扁平的版本，那么您缓存的数据应该看起来比后者更像后者。

When Patrick Cauldwell, Joe Tillotson, and Javan Smith worked on 800.com and Gear.com during the boom (800.com was bought by Circuit City and Gear.com was bought by Overstock.com) we built a series of multi-level caches that unfolded (de-normalized) the closer they got to the point of rendering, until we finally cached rendered HTML.

繁荣时期，当Patrick Cauldwell ，Joe Tillotson和Javan Smith在800.com和Gear.com上工作( 800.com被Circuit City收购， Gear.com被Overstock.com收购)时，我们建立了一系列的多层次缓存越接近呈现点就展开(反规范化)，直到我们最终缓存呈现HTML。

For sites that follow a regular navigation scheme (often that scheme is described by an XML file or in a Database...you know, nav.config, etc...we've all written one) the HTML of the headers, footers and navigation UI element (trees, pulldowns, tabs) should be cached if they are shared between more than one user.  Meaning, that if every user has a unique navigation, of course the ASP.NET Cache object isn't the place for them. 

对于遵循常规导航方案的网站(通常该方案由XML文件或在数据库中描述...您知道，nav.config等...我们都写了一个)，页眉，页脚HTML如果多个用户之间共享导航和UI元素(树，下拉菜单，选项卡)，则应对其进行缓存。 意思是，如果每个用户都有唯一的导航，那么ASP.NET Cache对象当然不是他们的理想之选。

In a site I'm working on now, there are (names changed to protect the innocent) Gold and Silver users.  Gold users see one set of navigation tabs, Silvers see another.  Additionally Gold and Silver users can be enrolled in additional programs, like Plan-A and Plan-B.  Whether a user is enrolled in Plan-A or Plan-B is not related to their membership in the Gold and Silver groups.

在我现在正在处理的站点中，有(为了保护无辜者而更改了名称)金和银用户。 黄金用户看到一组导航选项卡，白银用户看到另一组。 此外，金牌和白银用户可以加入其他计划，例如Plan-A和Plan-B 。 用户是否注册了Plan-A或Plan-B与他们在Gold和Silver组中的成员资格无关。

Additionally, the navigation tabs are drawn based on the current page (in Request.RawUrl).  Some navigation schemes that I am no longer a fan of are those that include techniques like Page.aspx?nav=tab1&subnav=subtab4&somethingsecret=somethingsilly.  I prefer to use liberal use of Url Rewriting and "simulated pages," like changing sitename/book.aspx?isbn=123 to sitename/123.book, etc.

此外，导航选项卡是基于当前页面(在Request.RawUrl中)绘制的。 我不再喜欢的某些导航方案包括那些诸如Page.aspx？nav = tab1＆subnav = subtab4＆somethingsecret = somethingsilly之类的技术。 我更喜欢自由使用Url重写和“模拟页面”，例如将sitename / book.aspx？isbn = 123更改为sitename / 123.book等。

For this site, we are just using page names and indicating in a navigation config XML file what tabs belong with what page.  For example:

对于此站点，我们仅使用页面名称，并在导航配置XML文件中指示哪些标签属于哪个页面。 例如：

<NAVIGATION>   <ROLE name="Gold">      <MENUITEM name="Accounts">         <SUBMENUITEM name="Balances">              <PAGE role="Plan-A">balances.aspx</PAGE>              <PAGE>transfers.aspx</PAGE>              <PAGE role="Plan-B">somethingelse.aspx</PAGE>          </SUBMENUITEM>       </MENUITEM>    </ROLE></NAVIGATION>...yada, yada, yada.  Of course, it's much more complex that this.  Each page also includes context sensitive help, user customizable links from a dropdown and a list of links that are related to the page their are on that the user may find interesting.  All of these are inter-related, making the XML file fairly normalized and complicating things.  When the file is finally deserialized, a series of hashtables and lookuptables are cached in memory for efficiency and used when rendering the menu.  The menu can render itself as a series of Tabs and SubTabs or a Tree, or whatever. 

<导航> <角色名称=“金”> <菜单项名称=“帐户”> <子菜单项名称=“平衡”> <PAGE角色=“ Plan-A”> balances.aspx </ PAGE> <PAGE> transfers.aspx </ PAGE> <PAGE role =“ Plan-B”> somethingelse.aspx </ PAGE> </ SUBMENUITEM> </ MENUITEM> </ ROLE> </ NAVIGATION> ... yada，yada，yada。 当然，这要复杂得多。 每个页面还包括上下文相关帮助，下拉菜单中的用户可定制链接以及与用户可能会感兴趣的页面相关的链接列表。 所有这些都是相互关联的，这使得XML文件相当标准化，并使事情变得复杂。 最终反序列化文件时，为了提高效率，将一系列哈希表和查找表缓存在内存中，并在呈现菜单时使用。 菜单可以将自己呈现为一系列选项卡和SubTab或一棵树，或任何其他形式。

The header/renderer is an ASCX file that asks the "NavigationService" for the details of the current navigation scheme, based on Context, in this case HttpContext.  A series of tests are done, checking .NET's role-based security for the user's roles.  Gold and Silver are mutually exclusive and Plan-A an Plan-B are not. 

标头/渲染器是一个ASCX文件，它基于Context(在本例中为HttpContext)向“ NavigationService”询问当前导航方案的详细信息。 完成了一系列测试，检查了.NET基于角色的用户角色安全性。 黄金和白银是互斥的，而计划A和计划B不是互斥的。

That means that given n pages, x mutually exclusive roles and y non-mutually-exclusive roles, there can be:

这意味着在给定n个页面， x个互斥角色和y个非互斥角色的情况下，可能有：

n * x * 2^y combinations of rendered headers

n * x * 2 ^y个呈现的标头组合

like:

喜欢：

balances.aspx : Gold
balances.aspx : Silver
balances.aspx : Gold : Plan-A
balances.aspx : Silver : Plan-A
balances.aspx : Gold : Plan-B
balances.aspx : Silver : Plan-B
balances.aspx : Gold : Plan-A : Plan-B
balances.aspx : Silver : Plan-A : Plan-B

balances.aspx：黄金balances.aspx：银balances.aspx：黄金：A计划balances.aspx：银：计划A balances.aspx：黄金：Plan-B balances.aspx：银：Plan-B balances.aspx：黄金：A计划：B计划balances.aspx：银：计划A：计划B

and on and on.  So, if you look at the 1*2*4=8 strings above, you can imagine them as keys in a HashTable.  We can cache Header two different ways (actually dozens, but let's make it simple):

等等。 因此，如果您看一下上面的1 * 2 * 4 = 8个字符串，可以将它们想象成HashTable中的键。 我们可以通过两种不同的方式缓存Header(实际上是几十种，但是让我们简单点)：

1. As Control objects in the Control Tree during the OnLoad.  If we see the same key again (the same page is visited with the same roles) we grab the Control objects from the HashTable, add them to the Control Tree.  Then the Control Tree will be turned into HTML in OnRender.  Cons: This would take some more memory than caching just the HTML; it takes more CPU to Render the Controls every page view.  Pros: If the Creation of the Control Tree that represents the navigation is expensive (more~ than ~50% of the totaly time it takes to fetch, build and render) then it's an easy change to implement if you're already building the navigation with HtmlControls in the code-behind.

1.在OnLoad期间作为控件树中的控件对象。 如果再次看到相同的键(以相同的角色访问相同的页面)，则从HashTable中获取Control对象，将它们添加到Control Tree中。 然后，控制树将在OnRender中变成HTML。 缺点：这将比仅缓存HTML占用更多的内存； 渲染每个页面视图的控件需要更多的CPU。 优点：如果创建表示导航的控制树很昂贵(超过获取，构建和渲染所花费的总时间的50％以上)，那么如果您已经在构建导航，则可以轻松实现在后面的代码中使用HtmlControls。

2. Using the directive with the VaryByCustom parameter like this:  .  Then, in the Global.asax you override GetVaryByCustomString, which will be automatically called by the Pages.   That's your opportunity to provide a KEY.  Not the HTML to cache, but rather the KEY by which to cache the rendered HTML.

2.将指令与VaryByCustom参数一起使用，如下所示：。 然后，在Global.asax中，您将覆盖GetVaryByCustomString，它将由Pages自动调用。 这是您提供KEY的机会。 不是要缓存HTML，而是要缓存呈现HTML的KEY 。

override public String GetVaryByCustomString(HttpContext current, String arg)
{
   switch(arg)
   {
      case "PageAndRolesKey": return GeneratePageAndRolesKey(current);
   }
}

覆盖公共字符串GetVaryByCustomString(HttpContext current，String arg) { 开关(arg) { 情况“ PageAndRolesKey”：返回GeneratePageAndRolesKey(current); } }

In this example, the GeneratePageAndRolesKey() function we'd look at the current page and current roles and build a key like: "balances.aspx : Silver : Plan-A."

在此示例中，我们将查看GeneratePageAndRolesKey()函数，以查看当前页面和当前角色并构建一个键，例如：“ balances.aspx：Silver：Plan-A。 ”

The rendered HTML is then stored in the Cache using the Key returned.  If the page is visited again, based on the key, the rendered HTML is retrieved from the Cache and all the slow generation code is bypassed. 

然后，使用返回的键将呈现HTML存储在缓存中。 如果再次访问该页面，则基于该键，将从缓存中检索呈现HTML，并跳过所有慢速生成代码。

To help me visualize and conceptualize, I like to say that there is one instance of a rendered header for each possible key. 

为了帮助我可视化和概念化，我想说的是每个可能的键都有一个渲染头的实例。

Pros: Easy to type, easy to implement incorrectly. :)

优点：易于键入，易于错误实施。 :)

Cons: Possibly hard to conceive of the cartesian explosion of 'flags.'  It's always useful to write out the equation and a table of key combinations.  The OutputCache directive caches the entire UserControl (ASCX) so you can't just cache a small portion of the UserControl.  The UserControl is the 'atom.'  You CAN, however, have multiple UserControls and cache each differently.  Be aware though that that can cause another combinatoric explosion if you're not careful.

缺点：可能很难想象笛卡尔的“标志”爆炸。 写出方程式和键组合表总是很有用的。 OutputCache指令缓存整个UserControl(ASCX)，因此您不能仅缓存UserControl的一小部分。 UserControl是“原子”。 但是，您可以有多个UserControl，并且每个缓存都不同。 请注意，如果不小心，这可能会导致另一个组合爆炸。

翻译自: https://www.hanselman.com/blog/aspnet-caching-and-cartesian-products

直积和笛卡尔积