Axapta当中的RunOn属性
来源:互联网 发布:java导出excel工具类 编辑:程序博客网 时间:2024/05/18 01:18
RunOn,顾名思义,就是指Object在那一层上面运行,客户端,还是服务器端?当然,前提是要在三层结构下面。Axapta当中与RunOn有关的,大概在以下这几个地方:
相关的Object,如Form, Report, Class等,Class当中的静态方法,以及MenuItem。
Form和Report是不能设置RunOn属性的,Form只能是运行在客户端,而Report则是由MenuItem所决定的,因为它的RunOn属性其实是被设为(Always)Called from的。当然,假如Report不用MenuItem指定激活的话,如直接在AOT当中用右键打开(Open),那就肯定是在客户端生成了。
那么剩下可以讨论的就是Class的RunOn属性,和Class当中的静态方法了。
静态方法,由它本身的modifier所决定。不写的情况下,默认为client server(可显式声明,一般情况下不用),也就是等于Called from,在哪里被调用就在哪里运行。
Class本身的RunOn属性是具有最高优先级的,只有当设置为Called from的时候,才会取决于MenuItem中的RunOn属性。还有一种情况就是,很多Class的main方法也指定了modifier,这个时候main方法的modifier比MenuItem更有优先权来决定Class运行的位置。
也就是说Class的RunOn属性 优先于 main方法的modifier 优先于 MenuItem的RunOn属性。
那么我们再来讨论这个RunOn属性的作用。
我们知道,在Axapta三层结构体系当中,不同层之间的调用,无论是方法,还是数据的交换,都会造成运行效率的降低。所以我们必须要尽可能减少不同层之间的调用。譬如说,某个Class具体的作用是进行数据运算,那么这个时候我们把它放在Client端运行是非常不合理的。因为这种情况下它需要和database进行大量的数据交换(中间需要通过AOS),所以我们就需要强制性的把它指定运行在AOS上,这样也可以减少了网内部的带宽消耗,更可以充分利用三层结构的优点,降低了客户端机器的负载。
然后还是有一个Best Practice原则,就是尽量把RunOn设置在MenuItem,而不要指定在Class本身的属性上面(尽量默认为Called from)。这样做的好处在于,可以灵活运用,因为某一个Class可以在不同的情况下,被指定运行在不同层上。开发人员只需要更改和使用不同的MenuItem,就可以达到这种效果。这也是Axapta里面所谓的API原则,尽量都通过MenuItem去激活和指定Object的运行状态。
- Axapta当中的RunOn属性
- Axapta当中的RunOn属性
- 善用Axapta当中的exists join和inner join
- 善用Axapta当中的exists join和inner join
- 反射当中的一些属性
- VIEW当中自定义属性的使用
- VIEW当中自定义属性的使用
- VIEW当中自定义属性的使用
- js当中对象属性的存储
- VIEW当中自定义属性的使用
- jsp当中提取struts2中action的属性值
- html 当中相关标签,元素,属性的缩写
- 为Yii bootstrap当中的TbDropDown 添加html属性
- Struts Spring整合当中属性驱动失效的相关解决
- VIEW当中三种自定义属性的方法
- 微软ERP Axapta 开发环境编辑器的快捷键大全
- M牛C原创博客——oc当中的属性问题
- 在session对象当中无法进行属性值参数的获取
- 怎样在下拉框中显示有过滤条件的数据
- 含着泪写给所有的女孩子
- 生活是不公平的,要去适应它
- 从一个form(Report)传递多个参数到另外一个form(report)
- 食用盐的12个美容方法
- Axapta当中的RunOn属性
- Export 到 Excel 完整的Job
- 把数字小写转换成大写,把数字转化成英文
- DOM元素属性
- Windows Server 2008 Enterprise使用12G内存
- 比较两行数据
- 避免一个用户多次登陆的解决方法
- 动态创建内容时所用的W3C DOM属性和方法
- 海量数据查询优化技巧