软件架构的心得以及个人见解和方法

 一直想写下自己对软件设计的一些体会，作为一个技术人员，早就应该总结下了，可是，需要总结的或许比较多，没有关系，路漫漫其修远～

如果，用一种有生命的眼光去看待软件，那么，架构是真正意义上的骨架了，何其重要，不言而寓

对架构来说，现在比较流行的20多种设计模式，如果能运用自如，有那么3到4种估计就足够满足了。

从开发到架构，这个中间是需要走很长一段时间的，但是我也相信，不具备宏观思考的人，是没有办法很好的规划一个软件架构的。一个好的架构，也是需要经过很长时间来修缮，补充的

首先，要说下的是面向对象的看法。

目前国内的大部分软件公司，大的也好，小的也好，中型的也好，有多少是用到面向对象的思想了呢，应该是很少一部分了。这个跟国内软件业的发展也有一定关系吧。

从项目的角度考虑，国内的项目一般都是短而快，要求速度的更多些，此类项目，最好不要有设计，需求整完以后直接使用面向过程的方式开发，会更好些

说远了～～～

对象这个东西，很难解释，有的时候，想从业务系统中将业务对象抽取出来，真的是比找老婆还要难

简单说来，就是一定要抓住重点，那么我的感觉就是，行为。行为非常重要。

一般情况下，在企业、政府机构的电子政务或者传说中的erp、oa系统中，大部分的行为总结来说就是增、删、查、改、统计这些标准的数据库操作了。涉及到业务运算的相对少些

通常，我们所说的封装，我理解，其实是封装行为。将行为封装了才能真正做到最合适的解耦。

假设，我们首先将通用数据的行为封装，设定一个接口，包括增、删、查、改

那么，这4个主行为基本就被定义出来。

然后我们来看属性。

使用大部分的代码或者实体的方式来定义一个对象（数据库中的某个表）也是个不错的方法，但是，我不是很喜欢用。我们可以更简单的定义一个属性读取器，负责专门给每个对象读取相对应的属性即可。

特殊行为，一定是存在与特定对象中的。

好的，考虑下设计的整体思路。

首先：我们需要定义一个框架，包括基类、数据库类、业务类、业务流程类、通用模块、数据传输、数据交互规则、数据字典

其中基类：在详细阅读完毕需求，我们发现，大部分的数据操作离不开上述的四个行为，所以这部分是可以通用的。

业务类：其实只包含了很少的代码，具体业务相关。

重要的是后面的几个部分。

我们来看一下数据交互规则。

所谓3层或者多层架构，能剥离业务操作和数据库的就是从数据交互来分的，或者说是UI层与业务层，业务层与数据库层之间的交互，要做到这3层很好的解耦，数据交互的规则就一定要设计好

这里数据交互的规则，我指的是，用户在界面中输入了数据，点击按钮以后，将信息提交到后台并且保存到数据库中的一个过程。

我们来看一个简单的添加操作。假设我们指定用户添加一个设备到数据库中。分析一下整个的设计过程。

第一，用户群组、权限、UI指定参数、按钮对应属性、全局对象接口方法、传入参数规则、调用方法。

好的，假设我们在页面中只写下面的代码

User use=new User(System.UserID);

Datastruct AddDataStract＝new  Datastruct(this.page);

bool bl=use.Enterprise.Equipment.Add(AddDataStract);

上面的代码为页面中的代码。

那么，我们首先需要定义顶层接口方法Add

然后定义顶层基类，实现接口中的Add方法

我们需要定义数据交互规则的数据结构Datastruct，作为数据交互的标准结构，并且实现大部分针对页面的读取操作

定义业务实体类。包括User、Enterprise、Equipment

在这里，我们视数据交互的结构体为单独的程序集，视采集页面数据为单独程序集，视接口、基类为程序集、视业务实体类为程序集

这样，清晰可见的3层架构：UI、业务、数据库（上面并没有描述数据库层的设计）。

累了，改天继续写写体会吧。