发帖    主题    评论    推荐    标签    作者    订阅    查搜    注册   登陆   关注
 
面向对象 设计模式 领域驱动设计 企业架构 框架 开发教程 微服务 CQRS 扩展性 并发编程 事件溯源 分布式 SOA
1 2 3 下一页 Go 3

基于任务的UI(Task-Based UI)

                   
2013-05-10 08:56
赞助商链接

基于任务的用户界面也被称为感应用户界面(响应式界面),做好基于任务的界面关键是要搞清楚用户想如何使用软件,并引导他们。当前,Web,移动,特别是苹果用户界面的设计趋势是基于任务驱动(Task-Based)。

基于任务的UI设计能够提供给你一个感知上下文的全新过程,可以始终保持你设计的正确方向,能够提供更好的用户体验,而用户的体验已经成为整个软件设计中一个不可或缺的组成部分。

当我们关注用户是如何使用该软件;,这实际上启动了我们对这个领域中动词的认识。

Task-Based UI主要介绍了一种基于任务的用户界面的概念,并比较它与传统CRUD风格的用户界面不同。 显示了在应用服务器后端切换到任务导向的风格时前端发生的变化。

传统“刻板架构”最大的问题之一是用户意图的丢失。 由于客户端与Application Server来回互动是以数据DTO为中心,在这个领域中没有任何动词。 领域实际变成了一个抽象数据模型。 在客户端,在纸上,或在该软件的用户脑子里都没有任何行为概念。

比如用户在屏幕xyz编辑foo为bar,然后再到其他屏幕编辑xyz到abc,我们的设计目标是:
在任何时候业务逻辑时只要改变工作流,而无需改变软件。

处理这个问题的方法之一是来自于DTO的向上/向下“定型架构”。

如下图,用户界面向服务器后端请求一个Customer的DTO对象,DTO返回到客户端时会在屏幕上显示。 用户以某种方式与DTO交互(例如DTO的一个视图模型)。 用户确认点击“保存”按钮,客户端将其确认的DTO发送到服务器后端。 后端服务器将这个DTO映射成领域模型,并保存更改,然后返回成功或失败。

在这里用户的意图被丢失了,因为客户端的“操作”完成后,发送的DTO只是代表对象的当前状态,而不是反映用户的那个“操作”意图行为本身,后端服务器应该接受用户提交的“操作”意图行为本身,而不是单纯执行这个意图(保存数据)。

banq补充:简单说,用户点按的按钮是“保存”, 服务器做的事情是"执行保存" ,两者不是一回事,"保存"是一个命令,而服务器做的事情是执行命令,而不是先接受这个命令,再执行这个命令。

打个比喻,司令部发出”攻占A山头“的命令,你的小组马上执行,跑到山头一看,没有敌人,你只能再打开命令文件查看,原来是A山头,你跑到了B山头;如果你当初刚接到命令时立即销毁了命令文件,你其实丢失了司令部的命令原始意图。

在DTO架构中,服务器端总是在实现执行,丢失"为什么要这么做"的信息,为什么要这么做?因为用户发出了”保存“指令,但是你在服务器端架构设计时,其实是丢失了这个"保存"指令,而是在执行保存指令,两者不是一回事。


[该贴被admin于2013-05-11 08:22修改过]


7
2013-05-10 09:09

捕捉意图的客户端交互前半段类似于基于DTO的交互,用户界面向服务器后端请求一个Customer的DTO对象,DTO返回到客户端时会在屏幕上显示,然后从这里开始就不一样了。

用户点按按钮后,客户端发送消息给服务器,告诉它做一些事情 (或者说命令它做事),可能是“完成一个销售”,“审批采购订单”,“提交贷款申请”等等。

客户端只是发送一个消息到服务器,让服务器完成用户想完成的任务。 明确地告诉服务器,用户想这样做,服务器能够知道用户的意图。

这里banq再补充几句:传统的MVC模式中,通常我们在控制器中实现了Action,其实Action本身是对Command的反应,我们在服务器前端要做的是先接受客户端指令,然后再进入应对和执行。

消息类似信封,命令类似信封里的内容,服务器前端应该首先是一种消息接收者,通过Command Handler取出信封的内容。

也就是说,在新的架构中,消息模式取代了以前的MVC模式,如果服务器前端是REST呢?恐怕REST的四个命令(GET POST DELETE UPDATE)也不足够表达用户的意图吧?

[该贴被admin于2013-05-11 08:21修改过]


2013-05-10 09:46

告诉服务器的方法是通过命令Command. 命令是一个简单对象,包括操作名称和需要执行操作的数据。命令可以看成是一个序列化的方法调用。

命令就是让服务器做事情。 命令语言学是很重要的,命令的定义可以设想如下场景:

一个断开连接的客户端发生了什么事情,如销售,这样可能要发送一个的“SaleOccurred”Command对象。 那么领域层是否可以对这个事情说NO? 如果服务器端可以拒绝这个事情就是一个命令,如果服务器不可以拒绝,那么它就是事件。


在英语语言中的有趣例子:““Purchase”购买”,这个词语可用于动词,也可以描述动词的结果:名词,在遭遇这种情况时,要确保的概念表示的是动词,而不是名词。 “购买”应包括购买什么,以及领域层期待的一些信息比如什么具体商品,而不是发送描述“购买”的DTO(这其实变成名词了)。

参考:
动词是个独裁者

2013-05-10 10:13

2013-05-10 09:46 "@banq
"的内容
果服务器端可以拒绝这个事情就是一个命令,如果服务器不可以拒绝,那么它就是事件。 ...


简单,精辟

2013-05-10 11:26

附图代码中的命令包括两个数据属性。 InventoryItem的ID和一个描述项目被停用原因的注释。 注释是和与命令相关联的属性,它是为了处理行为而所需的数据,这种为处理行为而准备的的命令数据点与传统DTO架构显著差异就是,这个对象整个数据是为了传输回服务器。

最重要的数据是ID相关的存货项目InventoryItem。它是对所有更新状态的命令是必须的,当然创建命令时就没有必要了。

开发人员应该普遍学习命令的定义,并非常迅速地开始使用命令来表达他们过去熟悉的CRUD词汇,如“改变地址ChangeAddress”,“创建用户CreateUser”,或“删除DeleteClass”等。 CRUD应该是默认避免的,这样整个团队能够集中关注用例是什么。


当电话公司将黄页发给搬迁到新地址时的客户时,是询问“ChangeAddress”? 还是更关注“更正地址Correcting an Address” 和 “重新定位客户Relocating the Customer”有什么区别?

是询问 “CreateUser”或者是 “RegisterUser”? “DeleteClass” or “DeregisterStudent”. 在这个过程中会培养对领域的洞察力,最好的方法是定义好用例,而命令是对应于用例的。(联系用例图 表达的正是某个操作角色做什么事情,这个做事情实际是一种命令)


值得注意的是,有时只有一部分数据的情况下,将只有“创建”,“编辑”,“更新”,“改变”或“删除”等CRUD操作。意识到这是支持所有的应用程序的简单信息。 但是不能落入陷阱,没有了解和这些CRUD相关用例中的意图(为什么要CRUD)。

命令作为一个概念并不难,但是对于许多开发者是不同的。 如果开发者把命令的定义看成代表很多工作要做,那么命令定义会成为一个瓶颈,这是不应该的。





3Go 1 2 3 下一页

赞助商链接

赞助商链接

返回顶部

移动版 关于本站 使用帮助 联系反馈 最佳分辨率1366x768
OpenSource JIVEJDON Powered by JdonFramework Code © 2002-20 jdon.com