、 某某架构1．从“层”上认识某某软件Software架构
软件Software业中Web最经典
架构必然是 3层架构:表现层
业务层数据层
那么让我们看看某某软件Software在 3层架构上是如何实现(如图1):层
项目
认识
表现层
Zivsoft.CRM
Zivsoft.CRM.Controller
表现层应该只对界面
表现形式做控制业务层
Zivsoft.Business
Zivsoft.Ajax
Zivsoft.Email
Zivsoft.Resource
Zivsoft.Report
业务层应该只跟具体需求有关系
是商业软件Software真正核心数据层
Zivsoft.Comm
数据层必须是独立
是必须可扩展层图1某某软件Software项目以 3层划分
从上面
表格中可以看出有 3层影子但再具体看项目发现 3层分得不太明确但又像MVC分层(如图2):层
项目
认识
Model
Zivsoft.Business
Zivsoft.Report
Zivsoft.Ajax
代表系统
模型层View
Zivsoft.CRM
模型
展现层Controller
Zivsoft.Controller
负责业务
流转图2某某软件Software以MVC层划分
总体上
感觉某某软件Software比较像MVC架构这是我认识总体感觉有架构影子但是似乎又没尽力做到最好2.从“开发模式”上认识某某软件Software架构
首先
我们从软件Software流程上来分析:假设我们现在从客户得到了
个新需求那么会有很专业人员理解需求并将需求带回公司某某在这环节做得很好如图3:3 客户需求提出
但是
需求分析后下步需求人员开始和
员沟通于是开始编码 即使员在编码前花了些时间做了设计工作甚至还拿到了文档(注:此文档般都是需求文档而非设计文档)具体流程如图4:
图4 需求到编码
跨越于是
接下来就开始走下流程(如图5):
图5 最耗时间
死循环那么现在让我们继续看下面
流程如图6:
图6 软件Software实施
现在对以上流程谈
下看法:在需求提出上
我个人认为做得很好当客户想要新功能无法用软件Software表现时需求人员提出自己解决方案让客户满意并将需求和解决方案带回公司回公司只要沟通没问题其实需求文档并不重要但般软件Software开发还是要写需求文档
需求文档毕竟是文档它可以便于以后复查这是它主要好处但是
我总认为软件Software是项工程某某流程走得似乎过于简单编码前设计和分析以及扩展性还有可行性另外现有框架是否满足这个新需求到来等等这些似乎没过多考虑而直接开始了编码工作先看看软件Software设计要做
事如图7:阶段
事务描述
概要设计文档
对需求人员提出
需求变成开发文档并分析是否可行可行继续写详细设计文档不可行和需求人员沟通对需求做出调整以适应开发继续做概要设计分析；另外有可能需要调整系统架构等等然后来适应开发和软件Software后续稳定性和扩展性详细设计文档
接口设计
设计者此时必须以开发人员
角色去分析需求并设计好接口数据库结构各表关联以及界面表现形式还有可能需要对架构等等加以调整和扩充从而满足新需求不会影响到已经存在模块数据库设计
界面设计
备注:
以上是我个人认为很重要
环节很多Bug都是事先考虑不周或者设计不合理导致以及扩展性难当然作为框架设计不合理也会导致新需求加入造成不稳定性而这切如此重要却被某某忽略于是总有“不稳性”阴影从而大家都在改永远改不完Bug没有事先设计从而让我们陷于如图5死循环中再回头已不能自拔(如Zivsoft.Comm,DataGrid动全惊动,杀掉个bug而另个新bug却悄悄诞生)图7 软件Software设计
重要环节被忽略作为流程后面
发布和测试我认为没有多大问题还是佩服某某花了大力气大人力来做这件事只是感觉祸源不在此其次
也就是最后要分析是研发内部开发模式:同样
从新需求开始分析当
个员接到新需求由于软件Software架构分了层那么分层另个好处却没有利用起来(本可以利用)我们先看图8:
图8 纵向开发
分层
好处不仅可以把业务独立让数据库容易扩展同时界面可以随意适应客户需求改变这是它主要好处的；另外分层在开发上它可以让区别特长员发挥它专长如对需求把握比较好人它可以去做表现层开发这样界面就比较统而且对需求实现也比较精确；若对需求把握不准可以去业务层开发它只需要实现被设计好接口另外所有业务的间关联如采购订单发货将会非常清晰；至于底层开发般需要性能分析以及架构知识但这块变化不大架构设计者可以开发这块现将上面纵向开发模式改成横向开发模式如下图9:
图9 横向开发
将图8
图9两张图进行比较你会发现员不需要知道跟它无关事情而且统了代码风格如表现层不会出现key和PKValue两种不统字段也不会出现按钮样式或按钮在各模块放位置不统；做完订单流程同时也知道到了发货流程该如何走它们关联清 2楚的间有什么关系做这层人肯定非常清楚而横横向的间衔接就是SOA思想下请求和响应你请求我响应这不会给的间带来沟通问题其实如果有设计文档这些提前已经设计好以上是从开发模式上认识某某软件Software架构
2、 架构改进
有了认识必然有
堆想法和建议以下我用图形式加以简略介绍说明,这样比较直观1．数据层架构图
图片看不清楚？请点击这里查看原图(大图)
图10 数据层架构
好
数据层旦建立随着业务扩充般不做修改只需要稍微维护即可在某某架构中数据层是非常薄弱而且被分到OKComm中这是不独立上面数据层架构比较复杂但从图可以看出它最大好处是:跟业务无任何关系只要是用到数据库软件Software都可以用到此数据层而且数据库是无限制扩展它是以SOA(面向服务架构)模式搭建只需要扩展服务即可使用新数据库而且借鉴了开源NHibernateORM机制让业务不出现任何Sql语句同时和物理表脱离从而达到数据库旦修改而不影响业务代码修改下面是数据库
扩展方式如图11:
图11 如何扩展数据库
2．业务层架构图
图片看不清楚？请点击这里查看原图(大图)
图12 业务层架构
业务层架构相对数据层架构
稍微简单些但是随着需求变化业务扩充业务比重将是整个架构核心从而成为软件Software企业重复利用商业业务库它好比个工厂在铸造零件当零件渐渐积累多了用它们来生产产品将越来越轻松软件Software企业亦是如此其实某某架构在业务上做得很不错
只是有些遗憾它像 3层架构但更像MVC所以Controller对于某某架构比重占得比较大如果是MVC架构那么可以说得过去但如果它采用是MVC架构那么我看到了OKBusiness这样个项目所以又不全是MVC架构以上架构图是对某某架构
改进它增加了业务索引我觉得业务代码像是个工厂零件库而业务索引就像书签便于查找作用同时去掉了Zivosft.Comm这个 4不像项目它似乎什么都是但却什么都不是于是我个人文为应该将它部分功能封装在IO层API中它毕竟是表现层和业务层衔接枢纽3．表现层架构图
图片看不清楚？请点击这里查看原图(大图)
图13 表现层架构图
如图13
由于SOA架构是面向服务架构所以业务层是表现层服务那么这就让表现层是最简单层它只做界面控制只需请求业务而已而实际上某某架构中刚才业务架构中提到它比重却占得比较大而且是把Zivsoft.CRM和Zivsoft.Controller分开改起来不方便在这层中将Plug-in引入是很多东西可以独立出来或者应用第 3方组件某某架构中DataGrid是个最典型见证而中间件定义和要求在图13中做了介绍说明3、 整理总结
记得大学里数据库老师说过
句话可以拿到这里做整理总结“做任何事应该把它当做项工程来做才能做好软件Software工程是项工程只有这样认识它才能做好软件Software”无论是在某某架构中还是在某某软件Software开发流程中最后整理总结建议就是:软件Software必须重视设计才像软件Software工程才能持久做好
最新评论