U-DCI理论

这里提出一个参与者概念，就是用例的参与者。
我们往往发愁与很底层的技术牵绊，比如request 和 response对象放在那里。
那么，如果一个User封装了request 和 response 呢，我认为是可行的。

以上的话，由于个人表达能力有限，但是仔细一想还是不错的解决方案。

那么，下面的写法或许将会被替换。


// 下面是老式的解决方案
server.get('/test',function(req,res){
  var role = new Role();
  var cxt = new Context(role);
  var result = cxt.run();
  res.send(result);
});


// 下面是新的解决方案 ，有一个道理，就是所有的场景肯定有其发动者User 。
eventbars ---> 事件总线调用
...
eventbars.on('/test',function(user){ // user 为用例参与者
  var role = new Role();
  var cxt = new Context(user,role);
  cxt.run();
});


// 在Context内部的User本身可能有如下的方法
user.command // 表示命令
user.listen(result)  // 表示听到的结果

当然，req和res都被User已经同化和融合了。

以上的是一种草图，我会用更准确的代码和言辞说明这些。
我们可以把这种架构成为 " U-DCI "

这个主意还是不错的，在Scala和Akka之中有一个Actor模型，Actor模型代表一个场景，又是一个容器，和其他场景之间是通过消息事件驱动，好像把DCI和事件比较好结合在一起，但是恐怕和Web容器结合还是有些问题的，因为Akka它们注重的是一种与客户端无关的架构，小型系统是通过Web的请求响应来驱动，大型系统可能是其他子系统通过事件来驱动了。
[该贴被banq于2011-05-16 09:12修改过]

这个U-DCI和我用liontseng发表的U-DCI不太一样，以前我想让 UIProxy 和技术层有所耦合，后来发现，不太好。

我在实际项目中用的的方式，类是与下面的代码。


app.get('/addnewpage',function(req,res){
   repo.user.findById(repo.user.WRITEMODE,req.session.loginuser.id,function(user){
       user.addNewPage(function(newpageid){
            if(newpageid){res.send('create new page success!')}
            else{res.send('create new page error!')}
       });
   })
})

当然 repository 我已经优化，不必每次都调用DB，repository会智能调用 store 内部方法进行持久化，因为持久化我们可以忽略，我们可以理解为“内存永存，所有的对象都在内存中存活” ，当然这个不太现实，不过应用代码会感觉如此。和DB一点关系都没有了。