为什么需要DTO

javaeye上有一篇帖子 – 为什么我的程序传递DTO
讨论了Domain Objec和DTO(Data Transfer Object)的关系,以及用Domain Object代替DTO的可能。我比较赞同其中的一个观点:

得出传递DTO不必要的结论,多半是因为应用过于简单,或者对于构建RichDomainModel缺乏经验导致的。完全OO的DomainModel,确实是值得追求的。

其实说来说去都是依赖谁的问题 – 是依赖Domain Object?还是只依赖服务层?这时就又有一个分歧了,Domain Object到底在你的心目中有多重?而这个问题在每个人的脑子都是不一样的。有时候这样的出发点的差异只会造成每个人都在固守己见而不去关心理解别人的着重点,最终变成毫无意义的争论。而没有对不同的情况系统的分析。

基本的几个着眼点:
1.觉得重复代码很多 – 想办法去写个类似hibernate的工具去帮忙 – 个人觉得已经从山脚下就跑偏了,只能绕着山脚跑
2.Domain Object是充血还是贫血
3.对Domain Object的依赖应该到persist layer,而服务层是面向更多不同的client(local的,remote的)去调用的,所以要避免对Domain Object的依赖,因为可能会暴露业务逻辑,或者存在Domain Object生命周期的问题(比如lazy load)。我觉得这一点却是要看的,如果认为Domain Object 只= (PO)Persistent Object,那么后一种论调可以合理解释。但是如果是纯粹的领域模型设计,那么所有的东西都应该也可以依赖 Domain Object,即便增加了DTO这个(说白了可以理解为Domain Object的proxy的东东)也还是存在Domain Object频繁变化带来的问题(这是个伪问题,领域对象变化的影响当然要“深远”,不可能用DTO来避免)

所以我的结论仍然是: It depends!

关于键盘mapper的想法

不知道这样的东西有没有:
通过无线接口(蓝牙或者红外)与PC连接,然后通过软件将键盘按键映射到一个类似遥控器的东西上
这个思路应该是很常见的,毕竟可以避免为每一种设备进行定制的重复性工作。当然这样的是需要PC端软件支持的。不是“天生”的。
不过应该也有相应的应用场景吧。比如ppt演示遥控器,将来通过电脑看电视时的遥控器,其实这个东西极端一点就是无线键盘了。只是可以定制,小一点,易用一点。

笔记 – UML基础 – 组件图

主要目的:显示系统组件间的结构关系

在 UML 2 中,组件被认为是独立的,在一个系统或子系统中的封装单位提供接口(一个或多个)。虽然 UML 2 规范没有严格地声明它,但是组件是呈现事物的更大的设计单元,这些事物一般将使用可更换的组件来实现。但是,并不象在 UML 1. x中,现在,组件必须有严格的逻辑,设计时构造

主要思想:你能容易地在你的设计中重用及/或替换一个不同的组件实现,因为一个组件封装了行为,实现了特定接口。

系统管理员发现组件图是有用的,因为他们可以获得将运行于他们系统上的逻辑软件组件的早期视图。虽然系统管理员将无法从图上确定物理设备或物理的可执行程序,但是,他们仍然欢迎组件图,因为它较早地提供了关于组件及其关系的信息(这允许系统管理员轻松地计划后面的工作)。

一个组件是提供一个或更多公共接口的独立单元。提供的接口代表了组件提供给它的用户/客户的服务的正式契约。

该例中,组件提供了名为 OrderEntry 和 AccountPayable 的接口。此外,组件也要求另外一个组件提供Person接口。
另一种显示方法:

–组件关系建模,简单的是就是要通过provided interface和required interface把所有组件连接起来。ps:接口定义了依赖

UML 2 规范在如何区别子系统与组件方面相当含糊。从建模的观点,规范并不认为组件与子系统有任何区别

UML 2 规范中说,何时该使用组件或子系统决定于建模者的方法论。 — 也就是说这是一个见仁见智的问题

组件图经常是一个架构师在项目的初期就建立的非常重要的图。然而,组件图的有用性跨越了系统的寿命。组件图是无价的,因为它们模型化和文档化了一个系统的架构。因为组件图文档化了系统的架构,开发者和系统可能的系统管理员会发现这一工作的关键产品有助于他们理解系统

组件图也视为软件系统配置图的输入。??

逼平东帝汶之后

看到输球之后媒体的那种表现于是有了一些思考。早就想写出来,无奈最近工作忙的要死,连点东西都抽不出时间来。
其实中国足球并不是中国足球队,虽然目前来看二者都不怎么样。但却没有排斥过国家队 – 只要他们能踢出好看的足球。中国足球代表的东西可就多了,包含了所有和足球有关的东西球员,俱乐部,老板,官员,媒体,球迷,足协。。。而中间提出一种共性的东西,那就是死要面子而又骨子里的不自信。

U16逼平东帝汶在我看来本没有什么大不了,足球的魅力就在于此 – 不可知,谁都可能被谁撂倒。不过这场比赛应该不是那种精彩纷呈最终没有开花结果的比赛,0比0,可以想象到。只是媒体的报道让我觉得搞笑,好像我们是多么不应该平。
一个世界排名100左右的球队和一个世界排名200左右的球队,通常国际足联不会是根据U16的战绩来的,U16如果有,那也是另一套。结果被媒体用这样的字眼一忽悠,民众便开始口诛笔伐,仿佛U16的“逼平”会影响到世界排名一样 – 把排名从100搞到101咋办啊!死要面子!

中国足球, 应该代表的是一种从足球相关的东西上折射出来的一种中国人性格。

再举个例子,赵薇同学刚刚说:“我很爱国,绝对不会嫁给新加坡人”,我可以理解赵薇同学的重点不在后半句,可是偏偏有人要把它理解为前半句。当然作为一个公众人物,在公众场合说出这种不经过大脑的话是不对。可是引起大多数“外籍情侣”的声讨恐怕就有点被媒体忽悠的意思。没准过两天赵薇还得跑出来道歉,向所有新加坡人道歉,向所有因为“嘴上”的问题而伤害的人们道歉。可是这。。。有意思吗?

N97使用感受

用N97快一个月了。感觉好坏一半一半吧。可能是因为还没有适应触摸屏吧,感觉使用速度上明显不如小6(e61i),当然e61i的运行速度很慢,但是靠着比较多的软件和已经成熟的s60v3系统,还是很好的满足了我的日常需要。
而N97目前的软件支持还很少,真的很少,几乎没有几个像样的软件,目前用的几个:
信安易 – 手机号码归属地查询,来电防火墙…
有道词典 – 类似google-translator的词典工具,不过觉得不如系统自带的英英词典好
smartmovie – 看电影
guita rock – 游戏,效果还不错,不过不是很喜欢玩
accuWeather – 有widget,可以放到桌面,自动联网更新天气
GMobileXT – GPS,不过貌似有点小问题 – 没有左右键,导致有的菜单进去以后无法退出
手机QQ – 可用
Notes on the phone – 启动后可以将屏保自动设置为便是贴的样子,作为提醒很不错
UCWeb7.0beta – 这个就不用说了,最好用的浏览器(但是目前因为cookie的问题,无法浏览google reader

ovi store还没有研究,看上去也不是很丰富的样子,稍微好一点的软件都要钱的

笔记 – SOA架构

SOA在互联网系统中的应用

三个话题 – 应用,系统,平台

soa规划
应用级:pojo,当团队更大,重新组织。应用级内部面向服务的问题 – 通过组件平台
企业级:系统之间的集成,支撑平台:bpm,esb,epm。企业服务库
产业级:变化快,更好的协同。作为服务提供者和协调者

application object — facade(策略+决策)-?
business object — manager(能力+操作)

spring帮助我们解决了关注点的分离

pojo编程模型 – validator的例子,todo:思考

组件模型抽象:
对象 – 操作和属性
组件 – 更多:生命周期,服务,扩展点,属性

交易流程 – 流程引擎组件

OSGi – java动态模块规范
bundle – 部署单元(模块)

既要引用模块化组件引入,又要让开发人员适应这种组件开发
spring dynamic modules
每个bundle独立的上下文-bean factory
只有允许发布服务的应用才可以被引用

三者的整合

jvm – 开发的场景
组件支持层 – 组件支持模型

交易支持不同交易方式 – 作为插件

安全可靠 -》互联网,用户需求,行业需求变化快

三层结构中,服务集成是最核心的部分,也是最难的部分
怎样把握服务内容以及抽象,从而更容易集成是目前我们有待解决的问题

《服务仓库》 — 不是很明白
从组件到服务,首要是组件模型的搭建,如果搭建好,自然很容易的国度
甚至可以对开发人员是透明的 – -我们目前可以做到吗?应该不可以

具体的例子《服务@alipay》
多个系统的协作
请求交易核心 – 创建交易
想银行集成平台请求,组装请求报文给银行请求划拨
银行向账户充值
银行向交易核心确认
支付宝内部的账户更新
返回商户平台
商户平台发出通知

在这样的规模(1秒以下)是可以做到的。

业务整理的过程
达到产品和业务核心的区分,核心全部通过服务完成

支付宝整合方式 – ESB企业服务总线(mule开源实现)
我们用esb做了什么?

<服务总线应用@alipay》
统一的事件封装和元数据模型,通过事件机制达到很好的协调

业务分布,数据分布 – 难题 – 事务

事务ACID -》BASE
BA – 业务处理主题必须是可用的,其他的可能不是可用的
交易,资金处理必须可用,消息发送可以不做,或滞后做

Soft state允许业务有偏出 – 只要不是关键部分
E – 对某些业务操作允许过一段时间再一致

“柔性事务” – “补偿性事务”

在大的业务里,对子业务进行区分,有些可以允许时间稍微晚一些,比如会计分录和交易通知
处理一致性的方法 – TCC模型
转钱的例子:1.完成检查,钱是否足够 2.预留钱
cancel或者confirm完成

有了服务的支持,通过协调框架完成协调 – 可以满足每天上千万的处理要求

第三部分:
生态圈的服务

企业内部服务化

开放平台,和合作伙伴更好的协同,超越企业的边界
传统网关方式三种:不需要讲
1.表单post
2.web rpc
3.异步通知

mashup – 太远了