封闭式开发小记(4)：封闭式开发的架构设计

这里主要简单介绍一下我们产品中主要WEB项目的构架思路,其它后台处理模块和通信服务端先略过.

我们的架构设计是基于REST的思想，由于这里篇幅有限，不对这种思想进行详细描述，这里只描述几个REST的原则：

   网络上的所有事物都被抽象为资源（resource）；
   每个资源对应一个唯一的资源标识符（resource identifier）；
   通过通用的连接器接口（generic connector interface）对资源进行操作；
   对资源的各种操作不会改变资源标识符；
   所有的操作都是无状态的（stateless）。

其实，之所以我们选用这种架构，主要是因为，我们的业务很多是无状态的，且不需要太多的事务性原子化操作。主要的业务都是展现。只是在查询的多样性方面会有一些要求。所以，我们的开发人员可以为相应的请求(URL)进行访问指定的资源。

由于MVC的种种好处，我们把MVC的使用方式进行了改造。我们并没有使用.NET MVC默认的Viewer,而是直接自己使用通用json格式,结合模板和JS代替．在走协议方面，当然还是基于http协议咯，毕竟是网络应用．但是我们没有使用原生的http的四个方法来实现.

由于原生的http方法是GET,POST,PUT,DELETE,可以对应CURD中的增删改查,但更多的暴露了太多数据结构,而把太多的状态的工作放到的URL上.

所以个人总结REST共有下面几句话:

1. REST是URL驱动的,URL的变化代替了内部的状态变化

2. REST 让WEB项目更像Winform项目了.

3. REST 对数据的依赖大于业务逻辑.在业务逻辑确定之后,可以按业务逻辑和流程,结合状态变化先订好URL地址,这样可以防止不同小组间的冲突.

4. REST 是个数据提供者,展现方式你自己决定.

5. REST 不适合处理复杂的业务逻辑和大量的状态迁移.

6. REST不仅仅可以走HTTP,也可以走TCP,或者HTML5中的Websocket.只要是按照前面的那几种原则来.

例子:

下面简单基于描述一个登录注册的例子,使用的是html5中的websocket

说明:

1. WS是使用websocket协议.

2. 一共有增加用户,更新用户信息,登录,和检查用户状态等功能.

3. 其中更新用户信息和登录都会指向下一个url ,即检用户状态的url.

也曾看过几篇关于REST的不好之处的文章,个人觉得有每个模式不是完美的,也有各自的优点和缺点,关键是你有那么多资源和时间吗?或者你能在尽可能短的时间内向TEAM的程员讲清楚,又能满足项目或产品的进度需求吗?如果上面几个问题都没问题,那用什么也没问题了.我们不是使用最完美的架构,而是此时此刻最适合的.