今天在整理资料时，无意看到一篇比较重要的内容，关于Umbraco的【常见陷阱与模式】。
在使用这类系统时，可能会受一些固化思维的影响，而忽略了系统本身的一些特性，导致一些类似于网站性能慢、反应慢、内存消耗高等问题。
通过该文章，应当可以规避一些问题。
大致包含一下一些方面：
使用单例和静态化：
一般来说，如果编写过一些软件的话，你应该会使用到依赖注入规则。如果你是这么做的，那么你可能不会使用单例和静态化（在大多数情况下，也不该如此！），然而由于Umbraco并不是一个开放IoC容器，因此你应该发现你使用的是Umbraco提供的：ApplicationContext.Current 或者 UmbracoContext.Current。在大多数情况下你不应该使用这些单例访问器，它使你的代码很难测试，但更重要的是使用单例和静态化会让你的代码难于管理，API泄露，最终导致出现更多的问题。
在所有的Umbraco基类中，你都可以使用它们暴露出来的属性，因此请使用它们进行替换！例如，在所有的Razor视图中，都由UmbracoContext暴露了UmbracoContext属性，由ApplicationContext暴露了ApplicationContext属性。在其他的基类中也都暴露了你所需要的实例，例如：SurfaceController,、UmbracoApiController,、UmbracoController、RenderMvcController,、UmbracoUserControl,、UmbracoPage、UmbracoHttpHandler，这个列表还将继续增加。
所以你下次使用【ApplicationContext.Current】或者【UmbracoContext.Current】时，可以思考『为什么我这样做？』【是否已经暴露为我所要使用的属性？】【我使用依赖注入，我应该注入这个实例到我的类中】
PS：大写的问号，【Singletons】和【Statics】这俩词真不知道该不该这么翻译。但是本章的意思，应该在于不要用类似于new ApplicationXXX()这样的方法去实现一个类，而是使用Umbraco提供的ApplcationContext和UmbracoContext这种属性操作数据。
静态引用Web请求实例（例如UmbracoHelper）：
private static _umbracoHelper = new UmbracoHelper(UmbracoContext.Current);
这种做法在使用_umbracoHelper时，会导致内存泄露以及数据的不一致。
为什么？
PS：好吧，，要点不需要理解，只要知道，不要生成静态对象，一般的私有变量就ok了。例如：
private _umbracoHelper = new UmbracoHelper(UmbracoContext.Current);
使用【Descendants】和【DescendantsOrSelf】查询：
这不是一个100%的错误，当数据量少的时候没什么，但是在数据量多的时候，系统会迭代每一个子集节点并存入内存。此功能慎用，建议用【Children】来替代。
使用过多的重复查询：
查询内容不是没有开销的。因此在使用同样的查询时，建议定义变量存储查询结果。
动态对象：
在Umbraco8+版本中，将删除IPublishedContent的动态操作支持。大致就是说避免使用【CurrentPage】，用【Umbraco.TypeContent】和【Umbraco.TypeMedia】代替【Umbraco.Content】和【Umbraco.Media】。
在视图中使用服务层：
Umbraco服务层是直接操纵umbraco业务逻辑到数据库。这些方法都不应该在您的视图中使用，并且对应用程序的性能和稳定性有很大的影响。例如：
var dontDoThis = ApplicationContext.Services.ContentService.GetById(123);
你的视图应该只依靠只读数据访问的umbracohelper暴露的属性和方法。这可以确保被查询的数据是快速的（来自缓存），并且您不会无意中进行数据库更改。
如果您正在视图中使用应用程序服务…那你至少应该弄清楚为什么这样做，在大多数情况下，最好删除这个逻辑。
不要通过【UmbracoContext】来操作 【ApplicationContext】；
不要用Umbraco Content Item来存储易变的数据，例如阅读量、访问量等
减少Linq的使用，而改用XPath
其他的，目前用不到，懒得再看了。。累死。。。。。
参考：
https://our.umbraco.org/documentation/Reference/Common-Pitfalls/