05 分析设计
文章平均质量分 69
virusswb
首先自我介绍一下,我叫史文彬,男,1981年生。2003年毕业于华北工学院,武器系统与发射工程专业,统招,学士学位。2007年毕业于中北大学,计算机应用技术专业,统招,硕士学位。
5年软件开发经验,3年电商开发经验,3年团队管理经验。主要平台为win+.net+sqlserver,也熟悉过ruby, linux, mysql, mongodb, redis。有较为丰富的设计开发经验,对于团队管理及建设也有自己的想法。不甘心于平凡,期待一个验证与实现自己的平台,想进入一个激情的团队,和一群激情的队友,一起实现大家的理想。
个人博客,http://virusswb.blog.51cto.com。
微博,http://weibo.com/virusswb。
耦合,谁之错?业务耦合,架构耦合,代码耦合,依次产生,前者是后者的催化剂,最终结果是系统严重耦合,无法适应任何变化。
这其中,业务耦合是根本,必须从根防治与修正,否则没有用,只会越来越差,最终崩塌。
当然,耦合也要从业务、架构、代码三个层面抓起,在每个层面减少耦合,为后面减少耦合打好基础。
展开
-
数据库的建立时机
数据库的建立应该在实体定义之后,由实体推出数据库。原创 2008-01-03 09:57:00 · 1181 阅读 · 0 评论 -
消息提示的架构演进-理论篇
项目是一个互联网应用。 假设项目有不同的用户群体,每个用户群体的前端都是一个独立的项目,交给不同的开发人员进行开发,前端和后端的交互方式选择WebService。 在前端和后端交互的过程中,主要有两类操作:一类是查询,包括返回单个记录和返回集合两种类型原创 2011-10-12 11:58:26 · 925 阅读 · 1 评论 -
架构演进-实例篇
1引言在标题的取名上,不敢说颇费心机,也算得上花费了一点功夫的。首先想到的是“架构设计过程”,又觉得是不是太大了,因为例子比较局部,不是很完整。叫做“结构变化过程”可能更好点。但是又怕名字取的小气了,进来的人少,参与讨论的就更少了,最终还是取了这个有点忽悠人的标题“架构演原创 2011-08-31 14:39:45 · 1059 阅读 · 0 评论 -
从Android中Activity之间的通信说开来
引言最近两个星期在研究android的应用开发,学习了android应用开发的基础知识,基本控件,基本布局,基本动画效果,数据存储,http访问internet等等基础知识。android中有一个概念,叫做activity。什么叫做activity呢?中文译为【活动】原创 2011-08-03 09:44:45 · 701 阅读 · 0 评论 -
帮助中国移动设计10086的排队小模块
1 引言 今天发现了伍迷的《大话数据结构》系列,应该不错,从第一篇开始阅读。因为之前就阅读过他的《大话设计模式》,觉得通俗易懂,而且从浅入深,结合实际情况,是一本不可多得的好书。 读到《《大话数据结构》第1章 数据结构绪论 1.2 你数据结构怎么学的?》这篇的时候,就出现了一个小的场景。他的学生小菜在工作中被分配了一个任务,完成一个客户排队模块的代码。小菜就建立一张表,保存每次的队列内容,客服空闲了,就拿出最早插入一条来给客服处理。结果被项目经理批了一顿,说他没有学过数据结构,用数据库干什原创 2011-04-19 06:25:00 · 1211 阅读 · 0 评论 -
我对DDD的认知(一)
1 引言 DDD,全名:Domain Driven Design,中文名:领域驱动设计。 2 DDD的分层 分层的架构方式是我们常用的,这里的分层是说n-layer,指的是逻辑的分层,目的是分离职责。常用的是三层:表现层,业务逻辑层,数据访问层。 DDD把原来经典三层(表现层,业务逻辑层,数据访问层)中的业务逻辑层又细分为两层:应用层和领域层。应用层负责领域对象的协调和调度,领域层包含具体的领域对象,领域规则(也就是业务规则),更大限度的实现业务规则的重用和职责的分离。将数据访原创 2011-04-07 03:38:00 · 1052 阅读 · 0 评论 -
通告(公告),消息(站内短信),提醒的设计:通告
1 业务描述 首先我们来认识一下通告,消息,提醒这三者的区别和联系。 1.1 通告Bulletin: 平台发,用户收。分为实时通告和非实时通告。通告有优先级:紧急,高,普通。 平台向单个用户发,平台向多个用户发,平台向某一个用户类型发,平台向全部用户发。 平台发布通告。 平台撤销通告。 平台删除通告。 平台查询通告。 用户查看通告。 用户查询通告。 数据库特点 一般不修改,每个用户一份,或者每个群体一份 1.2 消息Message(站内短信): 用户之间互相发消息,好比是手机短信原创 2010-11-26 09:35:00 · 5997 阅读 · 1 评论 -
自定义ORM系列(三)工具雏形及基本用法
<br /> <br />引言<br /> 本篇给大家介绍我这个工具的雏形结构,以及基本的用法,还请大家多提意见。<br /> 初看起来,这个有点像NHibernate。说到这里,肯定有人要拍砖了。其实,我也知道。我这个不入流的东西,和NHibernate相比差远了。我开发这个东西的原因主要有两个:<br /> 1)NHibernate太复杂了,学习了两个星期,觉得它太强大了。但是强大是用复杂做代价的,里面要学习的东西太多了,不敢轻易引入项目,因为很多原理不清楚,报错也不明确,所以不敢轻易在项目中使用原创 2010-12-21 19:09:00 · 774 阅读 · 0 评论 -
自定义ORM系列(二)发现属性是否修改,有选择的持久化
<br /><br /> 引言<br /> 今天给大家介绍的是ORM中的有选择持久化技术。现在的很多ORM工具都支持有选择的持久化,就是对于属性有选择的持久化。也可以理解为只持久化那些有变化的属性,忽略没有变化的属性。<br /><br /> 正文<br /> 很多时候我们想要知道实体的那些属性被更新,那些属性没有变化。<br /> 在很多的ORM工具中,在持久化数据的时候,可以判断哪些属性有值,哪些属性被更新过,这样的属性才会被持久化,没有动过的属性不会被持久化,而不是所有的属性都持久化。<br原创 2010-12-20 18:34:00 · 804 阅读 · 0 评论 -
胡乱说一下我对于 BO VO PO DTO 的理解
引言 本文中将向大家介绍我对于是使用实体的一些体验,欢迎大家拍砖。更欢迎提出不同或者相同的意见。 正文 刚开始学会使用实体的时候就是建立一个Entity类库,然后里面的实体被其他各层引用。大家传递和使用的都是这一个类库中的实体,包括前端和后台的项目都是引用这个类库,传递和操作这个类库中的实体。 就像上面的这幅图一样。每个都要添加对Entity的引用。每个项目都是这么做的,也没有发现什么不好的地方。 以前都是做一些小项目,或者是自己Demo一下。上面的做法也没有什么问题,而且看原创 2010-12-18 03:41:00 · 1452 阅读 · 0 评论 -
随笔写下的开发流程
刚才突发奇想,对于开发的流程有了一点新的想法。就发出来,供大家拍砖。不知道大家对这个流程有什么不满呢,尽管说,希望尽快完善它,尽快应用它。好了,说正文吧。 1 了解需求 就是了解客户,或者是市场的需求。可能要结合调研,深入体察,问卷调查之类的形式。尽可能了解市场的动向,方便把握我们的方向。 2 业务建模 了解的需求,定义的产品方向之后,就需要进行业务建模了。又可以分为三个阶段: 业务分析:分析市场的需求,划分业务的方向,找到业务的主体以及业务的大概内容和范围。 整理原创 2010-12-14 09:28:00 · 543 阅读 · 0 评论 -
谈谈我对实体的认识:DTO,DMO,DPO
今天和大家谈的是我对于实体的一些认识,难免有偏颇之初,还请各位指出。 大家都看到标题中的三个英文缩写了:DTO,DMO,DPO。DTO大家应该还是熟悉的,Data Transfer Ojbect(数据传输对象)。研究过DDD(Domain Driven Design领域驱动设计)的人应该了解过DTO。是用来传输数据的对象,应为领域对象虽然有数据(属性),但是领域对象上面还带有操作,在某些场合不适合进行传输,因为有些时候传输还需要序列化,而且也不是所有的领域对象属性都可以暴露给调用端的,而且有些属性可原创 2010-11-26 01:28:00 · 1836 阅读 · 0 评论 -
面向对象学习笔记--面向对象和面向过程
前几天看coffeewoo的专栏,他写了一本新书,thinking in uml,里面谈到面向过程方法和面向对象方法的区别和联系,第一次看的时候没有什么感觉,还是以前的感受。今天重新看了一遍,发现自己有了一点点的开窍了,接受了新的认识方法。现在把其中的一段摘抄了下来,原文链接http://coffeewoo.itpub.net/post/9169/294380面向过程方法和面向对象方法原创 2008-01-11 14:43:00 · 1224 阅读 · 0 评论 -
OO系统分析员之路学习笔记一用例
把用例解释为某个参与者actor要做的一件事可能更为合适。 1、这件事是相对独立的,意味着不需要与其他用例交互而独自完成参与者的目的。2、这件事的执行结果对参与者来说是可观测的和有意义的。3、这件事必须有一个参与者发起。4、这件事必然是以动宾短语形式出现。用例的背后是一种需求方法论,其核心是以参与者为中心(区别于以计算机系统为中心),从参与者的角度来描述他要做的日常工作(区别于原创 2008-01-11 16:29:00 · 1434 阅读 · 1 评论 -
面向对象学习笔记三--参与者
参与者actor在建模过程中占有核心地位,actor是在系统之外与系统交互的某人或者某事物。参与者位于系统边界之外,首先要明确边界。可以通过下面两个问题来确定,这两个问题非常有用,可以用来找出参与者和确定边界。1、谁对系统有着明确的目标和要求并且主动发出动作?2、系统是为谁服务的?其实更准的官方叫法是“业务主角business actor”,参与者容易让人误解为只要是参与了业务都是原创 2008-01-11 15:33:00 · 1609 阅读 · 0 评论 -
面向对象学习笔记二--建模
不论是在需求分析,系统分析还是系统设计上,读者一定要学会采用面向对象的方法,在面对问题领域的时候首先不要决定去通盘考虑,而是找出问题领域中包含的抽象角度。如果你把抽象角度都找全了,并且这些角度都分析清楚了,问题领域也就解决了。虽然这些抽象角度在思考的时候可能是互不关联的。具体来说,做需求的时候,首要目标不是要弄清楚业务是如何一步一步完成的,而是要弄清楚有多少业务的参与者?每个参与者的目标是什么原创 2008-01-11 15:12:00 · 1253 阅读 · 0 评论 -
Lucene学习笔记(1)
Lucene学习笔记 可以搜索文本文件,理论上可以搜索任何类型的数据。只要先把数据转化为文本,就可以对数据进行索引和搜索。 使用了反向索引的机制,维护一个词/短语的表,对于每个词和短语都有一个链表描述有哪些文档包含这个词和短语。这样用户输入查询条件的时候,搜索引擎先对输入的条件分词,分成词和短语,然后到建立好的索引上面查找,最终返回索引相关的文档。1、首先对文档进行分词。 2、原创 2011-10-24 18:54:07 · 971 阅读 · 0 评论