Umbraco常见陷阱与错误模式
2017-03-10 18:15
260 查看
今天在整理资料时,无意看到一篇比较重要的内容,关于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/
在使用这类系统时,可能会受一些固化思维的影响,而忽略了系统本身的一些特性,导致一些类似于网站性能慢、反应慢、内存消耗高等问题。
通过该文章,应当可以规避一些问题。
大致包含一下一些方面:
使用单例和静态化:
一般来说,如果编写过一些软件的话,你应该会使用到依赖注入规则。如果你是这么做的,那么你可能不会使用单例和静态化(在大多数情况下,也不该如此!),然而由于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/
相关文章推荐
- 五种 Ajax 反模式:避免常见的 Ajax 代码陷阱
- SessionState 的三种模式比较以及常见错误
- 技术文章 | vue工具帮你解决常见的错误与陷阱
- [转载]Go的50度灰:Golang新开发者要注意的陷阱和常见错误
- FTP常见错误及主动与被动模式问题
- [转载][翻译]Go的50坑:新Golang开发者要注意的陷阱、技巧和常见错误[1]
- [转]Go的50坑:新Golang开发者要注意的陷阱、技巧和常见错误-高级
- facebook快速登录常见错误:后台设置、域名权限、开发模式、公开、沙盒
- Go的50坑:新Golang开发者要注意的陷阱、技巧和常见错误[2]
- Go的50度灰:Golang新开发者要注意的陷阱和常见错误
- [转载][翻译]Go的50坑:新Golang开发者要注意的陷阱、技巧和常见错误[1]
- [转载][翻译]Go的50坑:新Golang开发者要注意的陷阱、技巧和常见错误[2]
- Flex数据绑定陷阱:常见的误用和错误(一) - 闪吧教材.jpg
- Hive1.2.1本地、远程模式安装配置及常见错误
- SpringMVC(7):单例模式在MVC框架的应用和分析常见缺陷(查询增加后的数据错误)
- 单例模式中最常见的双if语句错误
- nginx配置的常见陷阱及错误
- Go的50坑:新Golang开发者要注意的陷阱、技巧和常见错误[1]
- Python常见编程错误和陷阱
- 五种 Ajax 反模式:避免常见的 Ajax 代码陷阱!