Axapta当中的RunOn属性

 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的运行状态。