一些疑问

[forsakenyang]

看了下XUUI，按模块热重载的设计感觉很赞，配合FileSystemWatcher+lua可以实现做网页一样边改代码边看效果的体验了，不用重启在做UI方面能提升的效率是相当可观的

1. Adapter那块的设计不太理解，目前看起来是一个uGUI的组件对应一个Adapter？
   以Image为例，可以实现一个类似ImageAdapterSprite:DataConsumer这样去绑定组件上的精灵，那么Image上的其他属性也这样实现的话，这个类的数量好像会爆炸...

2. 在思路1里，在复杂UI界面GetComponentsInChildren的运行时开销可能会有点浪费？
   而且一个gameObject上的MonoBehaviour挂多了，反序列化的时间也会变长吧。
   思路2的话可以采用预生成+池回收的方式来管理各种RawAdapter，目前没想到有什么太大的问题

3. module之间可以嵌套吗，比如一个玩家列表，单个玩家的视图逻辑通常是作为组件重用的，用XUUI的话怎么做更优雅一些？

[chexiongsheng]

1、目前一个属性一个Adapter，我在实例里头同时监听下拉框的value和options时就有体会到这烦恼，类的个数，以及如何命名的问题，我在想是否能提供一种新的绑定方式：绑定路径指定到一个table，然后相应字段就至少能单向同步到c#同名属性。如果双向同步，就比较难办了，需要提供注册和去注册能力，没地方存不好办。

2、思路1的Adapter就是MonoBehaviour的设计从开销看比较重，不过胜在清晰：节点上直接挂绑定信息。而思路2则轻量级些，个人觉得不如思路1清晰（也有人反馈即使不考虑开销，也喜欢这种方式）。不过两个思路记录的信息是一样的，其实可以通过提供工具转换（配置时按思路1，可转换成思路2供运行时用），而且即使是RawAdapter，最好也是按你说的一些建议来优化表现；

3、我原设想的建议组织方式是Context（VM+Commads）全局一个，而Context只划分一级module，像切换主UI，弹窗和关闭弹窗，都可以看作是一个个View的Attach和Detach，所有View用全路径绑定到各modules。
你说的“module之间可以嵌套”具体是？module下还有子module么？这个貌似没能很好的解决你举的例子吧？
多模块间重用视图的需求是存在的但之前没考虑得很好的，这么处理你觉得怎样？
a、无交互逻辑，这核心冲突是这个重用模块只能设置一个绑定路径，是不是可以通过绑定“相对路径”的方式来解决，在Attach（也有lua对应的接口）时可以传递一个根路径，或者根路径所指向的table来解决；
b、有交互逻辑，则需要新建一个Context来实现，开放接口来供外部调用；

[doukouDAI]

看了下代码，不是很明白computed_bind是怎么回事，不知道是否可以解释下，谢谢！

[UpUpLiu]

a、无交互逻辑，这核心冲突是这个重用模块只能设置一个绑定路径，是不是可以通过绑定“相对路径”的方式来解决，在Attach（也有lua对应的接口）时可以传递一个根路径，或者根路径所指向的table来解决；

我觉得这个是可行, 可用于解决各种小的 比如scrollview这种界面的绑定