04 模式架构
文章平均质量分 92
virusswb
首先自我介绍一下,我叫史文彬,男,1981年生。2003年毕业于华北工学院,武器系统与发射工程专业,统招,学士学位。2007年毕业于中北大学,计算机应用技术专业,统招,硕士学位。
5年软件开发经验,3年电商开发经验,3年团队管理经验。主要平台为win+.net+sqlserver,也熟悉过ruby, linux, mysql, mongodb, redis。有较为丰富的设计开发经验,对于团队管理及建设也有自己的想法。不甘心于平凡,期待一个验证与实现自己的平台,想进入一个激情的团队,和一群激情的队友,一起实现大家的理想。
个人博客,http://virusswb.blog.51cto.com。
微博,http://weibo.com/virusswb。
耦合,谁之错?业务耦合,架构耦合,代码耦合,依次产生,前者是后者的催化剂,最终结果是系统严重耦合,无法适应任何变化。
这其中,业务耦合是根本,必须从根防治与修正,否则没有用,只会越来越差,最终崩塌。
当然,耦合也要从业务、架构、代码三个层面抓起,在每个层面减少耦合,为后面减少耦合打好基础。
展开
-
胡乱说一下我对于 BO VO PO DTO 的理解
引言 本文中将向大家介绍我对于是使用实体的一些体验,欢迎大家拍砖。更欢迎提出不同或者相同的意见。 正文 刚开始学会使用实体的时候就是建立一个Entity类库,然后里面的实体被其他各层引用。大家传递和使用的都是这一个类库中的实体,包括前端和后台的项目都是引用这个类库,传递和操作这个类库中的实体。 就像上面的这幅图一样。每个都要添加对Entity的引用。每个项目都是这么做的,也没有发现什么不好的地方。 以前都是做一些小项目,或者是自己Demo一下。上面的做法也没有什么问题,而且看原创 2010-12-18 03:41:00 · 1452 阅读 · 0 评论 -
小议传统分层与新式分层,抑或与DDD分层
引言 本文提到的分层只是软件架构上的分层。文中的传统分层指的是传统的三层结构:UI(界面表现层),BLL(业务逻辑层),DAL(数据访问层)。文中提出的观点也都是个人的一点认识,与任何组织没有关系,如有异议,还请各位踊跃拍砖。 当然了,出现的这些问题,也可能只是我个人的问题,不代表每个人都存在。无则加勉,有则改正吧。如果是个人的问题,那就当是个人总结吧,大家看看就算了。 这里说到的传统分层,也有可能是我对于分层的错误理解造成的,但是我看见的不只是我的项目是这么的结构,很多的项目也都是这样的结构。原创 2011-01-10 06:37:00 · 1653 阅读 · 1 评论 -
架构演进-实例篇
1引言在标题的取名上,不敢说颇费心机,也算得上花费了一点功夫的。首先想到的是“架构设计过程”,又觉得是不是太大了,因为例子比较局部,不是很完整。叫做“结构变化过程”可能更好点。但是又怕名字取的小气了,进来的人少,参与讨论的就更少了,最终还是取了这个有点忽悠人的标题“架构演原创 2011-08-31 14:39:45 · 1059 阅读 · 0 评论 -
消息提示的架构演进-理论篇
项目是一个互联网应用。 假设项目有不同的用户群体,每个用户群体的前端都是一个独立的项目,交给不同的开发人员进行开发,前端和后端的交互方式选择WebService。 在前端和后端交互的过程中,主要有两类操作:一类是查询,包括返回单个记录和返回集合两种类型原创 2011-10-12 11:58:26 · 925 阅读 · 1 评论