那些年——7 286&586

易德军 说 (10:45):
谈2个问题
寒林 说 (10:45):
怎么了？
易德军 说 (10:46):
那 我就可以 用你的账号和密码 登录系统 看你的东西了？！
寒林 说 (10:47):
对的
寒林 说 (10:47):
这是毫无疑问的事情
寒林 说 (10:47):
不过商业系统当然有保密规则在里边 而且还会对一些用户信息进行加密
寒林 说 (10:48):
你自己做的由于没有这些法律法规的限制 所以比较随意了
寒林 说 (10:48):
一般系统里面 密码都是密文的
寒林 说 (10:48):
不是明文的
易德军 说 (10:49):
hehe 所以 我就想 那管理银行系统后台的 肯定知道我们的账号和密码

寒林 说 (10:49):
不一定
寒林 说 (10:49):
银行系统里不会明文有你的密码
寒林 说 (10:49):
记录里是密文
易德军 说 (10:49):
入库时 加密 是肯定的
可是 开发者 可以相应解密 不就知道了吗 呵呵
寒林 说 (10:50):
有时候是用不可逆算法的
寒林 说 (10:50):
数据库里存的是MD5编码 没办法逆转运算
易德军 说 (10:51):
是这样啊 我以为 所有的加密 都可解密呢
寒林 说 (10:51):
有些加密算法是不可逆的
寒林 说 (10:51):
md5的不可逆转性 这个应该知道吧
易德军 说 (10:51):
不知道 呵呵
易德军 说 (10:52):
我最近 才看加密 这些东西
寒林 说 (10:52):
呵呵
寒林 说 (10:53):
MD5是最常见的不可逆加密算法
易德军 说 (10:54):
为什么 不可逆呢？这MD5 有些特殊？！
寒林 说 (10:54):
自己看看就知道了
易德军 说 (10:54):
不过 看来 这不可逆 还是 很有必要的
寒林 说 (10:54):
呵呵
易德军 说 (10:55):
要不 那完蛋了 我的账号 密码 人家都知道了 呵呵
寒林 说 (10:55):
呵呵 我说了 这些东西可以保障不知道 但是你没办法规范服务提供方这么做
易德军 说 (10:55):
呵呵
易德军 说 (10:56):
还有个疑问
易德军 说 (10:56):
java的
易德军 说 (10:58):
都是 web 系统new 的对象越少越好
那 我给它 都搞个静态方法 呵呵 都不用new了
可 为什么 又都不这么做呢
这 肯定是有原因的
易德军 说 (10:58):
都说
易德军 说 (10:59):
还有 就是类似的 单态模式
寒林 说 (10:59):
谁说的new的越少越好？
易德军 说 (10:59):
以前 网上看到的 呵呵
寒林 说 (10:59):
扯淡
寒林 说 (11:00):
做开发要考虑两方面
寒林 说 (11:00):
设计 和 效率
寒林 说 (11:00):
在效率方面考虑 可以分为长期驻留内存对象和临时对象
寒林 说 (11:01):
临时对象可以说是new的越少越好 这里为了解决性能问题多数是用object pool来解决的
寒林 说 (11:01):
在设计上 static 是一种违反 oop原则的语法结构
寒林 说 (11:02):
而且大量的static对象 会导致无法进行垃圾回收
易德军 说 (11:02):
原来如此
寒林 说 (11:03):
大量的new也只是会导致jvm的 新区和旧区的大量交换 以及旧区的频繁回收
寒林 说 (11:03):
这要整体来考量 你的内存总量 对象总量 回收频率 才能决定性能是否有问题
寒林 说 (11:04):
如果都是常驻内存对象 会不会导致内存溢出之类的
易德军 说 (11:05):
比如说啊：
易德军 说 (11:07):
一个Action 中 new了一个对象
此时有n个人使用次系统，那是不是，服务器（jvm）内存中就会有了n个此对象
寒林 说 (11:08):
对
易德军 说 (11:11):
那现在：我每个Action中都调用service层的一个对象
如果每个Action中 都通过new个次对象的话，那多个Action就会有多个此对象new出来
那我给这个Service层的对象 搞成单态的 是不是可以
易德军 说 (11:11):
没有用 Factor模式
寒林 说 (11:11):
可以
寒林 说 (11:11):
这样是可以的
易德军 说 (11:13):
呵呵 这样的单态的 是不是要 比那每个Actoin都new 要好许多？
寒林 说 (11:14):
对的 这个地方是这样
寒林 说 (11:14):
因为你这不是VO
易德军 说 (11:14):
VO 什么东西啊？
寒林 说 (11:14):
自己想
易德军 说 (11:14):
我Google Google 呵呵
易德军 说 (11:17):
呵呵
VO是什么？它是值对象，准确地讲，它是业务对象，是生活在业务层的，是业务逻辑需要了解，需要使用的，再简单地讲，它是概念模型转换得到的。
易德军 说 (11:17):
有道理 比如：Book 对象 要搞个单态的 那估计就没有什么意义了
寒林 说 (11:19):
呵呵
易德军 说 (11:20):
一个VO可以只是PO的部分，也可以是多个PO构成，同样也可以等同于一个PO（当然我是指他们的属性）。
易德军 说 (11:21):
呵呵 这些概念和术语 看来有必要 知道

PO是持久化对象，它只是将物理数据实体的一种对象表示，为什么需要它？因为它可以简化我们对于物理实体的了解和耦合，简单地讲，可以简化对象的数据转换为物理数据的编程。VO是什么？它是值对象，准确地讲，它是业务对象，是生活在业务层的，是业务逻辑需要了解，需要使用的，再简单地讲，它是概念模型转换得到的。FormBean又是什么？它只是HTML表单的封装，是为了在控制层弱化request中存储数据的作用，将request的get方法转变为对象的存取值。

理清了上述概念，好，我们就开始讨论，为什么需要它们，为什么不需要它们。首先说PO和VO吧，它们的关系应该是相互独立的，一个VO可以只是PO的部分，也可以是多个PO构成，同样也可以等同于一个PO（当然我是指他们的属性）。正因为这样，PO独立出来，数据持久层也就独立出来了，它不会受到任何业务的干涉。又正因为这样，业务逻辑层也独立开来，它不会受到数据持久层的影响，业务层关心的只是业务逻辑的处理，至于怎么存怎么读交给别人吧！不过，另外一点，如果我们没有使用数据持久层，或者说没有使用hibernate，那么PO和VO也可以是同一个东西，虽然这并不好。其次，让我们看看FormBean和VO，如果简单地讲，我们是可以不需要FormBean的，它只是struts带来的一部分，而VO是无论如何不能舍弃的。如果让FormBean直接到业务层（它本来应该生活在控制层），那么会带来什么？View和Model就出现了强耦合，如果想改一下view的表示，整个业务逻辑都得改，恐怖的事情啊！

这些对象概念的出现其实就是体现了一种层的思维，也是体现了一种框架的思维，在层与层之间我们需要什么？我们应该怎么通信，其实大家认真地用笔画上几个图就可以知道了。做web应用尤其是企业应用，切忌像楼上某些朋友说的，一个东东从头到尾，那是非常低劣和错误的设计。我们不要单纯地就为了某些对象去争论什么，它们更多的只是思维。这样的思维给我们带来了哪些好处，不言自明，当然，我们也不得不否认，我们因此失去了某些东西，比如局部的性能或者繁琐的代码和调用过程，只是自己衡量一下，它是否值得。