说一些我自己的观点，不一定对，但是绝对是实际中的经验：
关于三层架构我比较推荐的模式：
client --> com+(控制事务,封装企业对象) 中间层服务器 --> 数据存储服务器（无事务控制）
各层之间通过接口完成调用，一般来说数据存储层 写好了就不动，
com+(控制事务) 中间层服务器 用来写企业对象（业务逻辑）
client 只是负责界面显示，调用，这样的三层结构是最理想的。
但是 实际中，由于各种原因（比如业务经常变动、代码或者思考逻辑上的错误、
团队内部设计人员、编码人员的能力问题、编码习惯问题等等
等等原因会造成企业对象的频繁改动，这样常常容易造成com+ 这一层的企业对象
过于庞大，复杂，再加上com+ 这一层的服务器调试比较特别，没有表现层，
所以如果你认为你的团队把企业对想写在com+这一层不是很合适的，那么我推荐
下面的模式）
client（表现层和企业对象分离） --> com+(控制事务) 中间层服务器 --> 数据存储服务器（无事务控制）
这种模式虽然不是标准三层的推荐写法，但是我觉得这种模式还是由他的好处的，
把客户端分成表现层和业务逻辑层（企业对象），一则可以实现标准三层的写法
（基本上的mvc，并且抽象出了业务类--企业对象），再则调试简单，增加开发效率，
节约成本。扩展性：以后当你的企业对象基本上已经很完善，不需要作太多改动的
时候，这个企业对象可以很容易的搬到 com+ 服务器这一层。
最后回答楼主的问题：
企业对想说的复杂一些，可以是一个很复杂的类，比如可以是
一个很复杂的仓库业务，简单一点的可以是一个方法，或者数据校验等，
而客户端表现层需要做的东西就是根据你取得数据、业务逻辑 、流程等
需要在客户端表现的东西，比如楼主说的 在如何构建一个树，等等都属于
表现层的东西。
以上 都是个人意见，如有不妥，清高手赐教，继续听高手讲课...
