对某某软件架构认识与建议(非原创)

最新推荐文章于 2023-07-25 23:54:26 发布

GeneralXCK

最新推荐文章于 2023-07-25 23:54:26 发布

阅读量635

点赞数

分类专栏：设计模式与系统架构文章标签：数据库文档 mvc datagrid 扩展 soa

本文链接：https://blog.csdn.net/GeneralXCK/article/details/5350997

版权

设计模式与系统架构专栏收录该内容

8 篇文章 0 订阅

订阅专栏

一、某某架构

1．从“层”上认识某某软件架构

软件业中Web最经典的架构必然是三层架构：表现层，业务层，数据层。那么让我们看看某某软件在三层架构上是如何实现的（如图1）：

层	项目	认识
表现层	Zivsoft.CRM Zivsoft.CRM.Controller	表现层应该只对界面的表现形式做控制
业务层	Zivsoft.Business Zivsoft.Ajax Zivsoft.Email Zivsoft.Resource Zivsoft.Report	业务层应该只跟具体需求有关系，是商业软件的真正核心。
数据层	Zivsoft.Comm	数据层必须是独立，是必须可扩展的一层。

图1某某软件项目以三层划分

从上面的表格中，可以看出，有三层的影子，但再具体看项目，发现三层分得不太明确，但又像MVC分层(如图2)：

层	项目	认识
Model	Zivsoft.Business Zivsoft.Report Zivsoft.Ajax	代表系统的模型层
View	Zivsoft.CRM	模型的展现层
Controller	Zivsoft.Controller	负责业务的流转

图2某某软件以MVC层划分

总体上，感觉某某软件比较像MVC架构，这是我的认识。总体感觉有架构的影子，但是似乎又没尽力做到最好。

2.从“开发模式”上认识某某软件架构

首先，我们从软件流程上来分析：

假设我们现在从客户得到了一个新的需求，那么，会有很专业的人员理解需求，并将需求带回公司。某某在这一环节做得很好，如图3：

图 3 客户需求提出

但是，需求分析后的下一步，需求人员开始与程序员沟通，于是开始编码，即使程序员在编码前花了一些时间做了设计工作，甚至还拿到了文档（注：此文档一般都是需求文档，而非设计文档），具体流程如图4：

图4 需求到编码的跨越

于是，接下来，就开始走一下流程(如图5)：

图 5 最耗时间的死循环

那么现在让我们继续看下面的流程，如图6：

图6 软件实施

现在对以上流程谈一下看法：

在需求提出上，我个人认为做得很好，当客户想要新的功能，无法用软件表现时，需求人员提出自己的解决方案，让客户满意，并将需求与解决方案带回公司。回公司，只要沟通没问题，其实需求文档并不重要，但一般软件开发还是要写需求文档，因为需求文档毕竟是文档，它可以便于以后复查，这是它的主要好处。

但是，我总认为，软件是一项工程，某某的流程走得似乎过于简单，编码前的设计与分析，以及扩展性，还有可行性，另外现有的框架是否满足这个新需求的到来，等等，这些似乎没过多考虑，而直接开始了编码工作。

先看看软件设计要做的事如图7：

阶段		事务描述
概要设计文档		对需求人员提出的需求变成开发文档，并分析是否可行，可行继续写详细设计文档，不可行和需求人员沟通对需求做出调整，以适应开发，继续做概要设计分析；另外有可能需要调整系统架构等等，然后来适应开发和软件的后续稳定性和扩展性。
详细设计文档	接口设计	设计者此时必须以开发人员的角色去分析需求。并设计好接口，数据库结构，各表关联，以及界面表现形式。还有可能需要对架构等等加以调整和扩充，从而满足新需求不会影响到已经存在的模块。
	数据库设计
	界面设计
备注：		以上是我个人认为很重要的环节，因为很多的Bug都是因为事先考虑不周，或者设计不合理导致的，以及扩展性难，当然作为框架设计不合理，也会导致新需求的加入造成不稳定性，而这一切如此重要，却被某某忽略，于是总有“不稳性”的阴影，从而大家都在改永远改不完的Bug。因为没有事先的设计，从而让我们陷于如图5的死循环中，再回头已不能自拔（如Zivsoft.Comm,DataGrid一动全惊动,杀掉一个bug，而另一个新bug却悄悄诞生）。

图7 软件设计的重要环节被忽略

作为流程后面的发布与测试，我认为没有多大问题，还是佩服某某花了大力气，大人力来做这件事。只是感觉祸源不在此。

其次，也就是最后要分析的是研发内部的开发模式：

同样，从新需求开始分析。

当一个程序员接到新需求，由于软件架构分了层，那么分层的另一个好处却没有利用起来（本可以利用），我们先看图8：

图8 纵向开发

分层的好处不仅可以把业务独立，让数据库容易扩展，同时界面可以随意适应客户需求的改变，这是它的主要好处之一；另外，分层在开发上，它可以让不同特长的程序员发挥它的专长。如对需求把握比较好的人，它可以去做表现层的开发，这样界面就比较统一，而且对需求的实现也比较精确；若对需求把握不准，可以去业务层开发，因为它只需要实现被设计好的接口，另外所有的业务之间的关联，如采购，订单，发货，将会非常清晰；至于底层的开发，一般需要性能分析，以及架构的知识，但这一块变化不大，架构，设计者可以开发这一块。现将上面的纵向开发模式改成横向开发模式，如下图9：

图9 横向开发

将图8，图9两张图进行比较，你会发现，程序员不需要知道跟它无关的事情，而且统一了代码风格，如表现层不会出现key和PKValue两种不统一的字段，也不会出现按钮样式或按钮在各模块放的位置不统一；做完订单流程，同时也知道到了发货流程该怎么走，它们的关联一清二楚，之间有什么关系，做这一层的人肯定非常清楚。而横横向之间的衔接，就是SOA思想下的请求与响应。你请求，我响应，这不会给程序之间带来沟通问题。其实如果有设计文档，这些提前已经设计好。

以上是从开发模式上认识某某软件架构。

二、架构改进

有了认识必然有一堆想法与建议，以下我用图的形式加以简略说明,这样比较直观。

1．数据层架构图

图10 数据层架构

好的数据层一旦建立，随着业务的扩充，一般不做修改，只需要稍微维护即可，在某某架构中，数据层是非常薄弱的，而且被分到OKComm中，这是不独立的，上面的数据层架构比较复杂，但从图可以看出它的最大好处是：跟业务无任何关系，只要是用到数据库的软件都可以用到此数据层，而且数据库是无限制扩展的，因为它是以SOA(面向服务架构)模式搭建，只需要扩展服务即可使用新的数据库，而且借鉴了开源NHibernate的ORM机制，让业务不出现任何Sql语句，同时与物理表脱离，从而达到数据库一旦修改而不影响业务代码的修改。

下面是数据库的扩展方式，如图11：

图11 如何扩展数据库

2．业务层架构图

图12 业务层架构

业务层架构相对数据层架构，稍微简单一些，但是随着需求的变化，业务的扩充，业务的比重将是整个架构的核心，从而成为软件企业重复利用的商业业务库。它好比一个工厂在铸造零件，当零件渐渐积累多了，用它们来生产产品将越来越轻松，软件企业亦是如此。

其实某某架构在业务上做得很不错，只是有一些遗憾，因为它像三层架构，但更像MVC，所以Controller对于某某架构比重占得比较大，如果是MVC架构，那么可以说得过去，但如果它采用的是MVC架构，那么我看到了OKBusiness这样一个项目，所以又不全是MVC架构。

以上架构图是对某某架构的改进。它增加了业务索引，因为我觉得业务代码像是一个工厂的零件库，而业务索引就像书签，便于查找的作用。同时去掉了Zivosft.Comm这个四不像的项目，因为它似乎什么都是，但却什么都不是，于是我个人文为应该将它部分功能封装在IO层的API中，因为它毕竟是表现层与业务层衔接的枢纽。

3．表现层架构图

图13 表现层架构图

如图13，由于SOA架构是面向服务的架构，所以业务层是表现层的服务，那么这就让表现层是最简单的一层，因为它只做界面控制，只需请求业务而已。而实际上某某架构中，刚才业务架构中提到，它的比重却占得比较大，而且是把Zivsoft.CRM与Zivsoft.Controller分开，改起来不方便。在这一层中将Plug-in引入，是因为很多东西可以独立出来，或者应用第三方的组件，某某架构中的DataGrid是一个最典型的见证。而中间件的定义和要求在图13中做了说明。