这里主要简单介绍一下我们产品中主要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的程员讲清楚,又能满足项目或产品的进度需求吗?如果上面几个问题都没问题,那用什么也没问题了.我们不是使用最完美的架构,而是此时此刻最适合的.

引用

CRUD不适合REST吗？

http://www.infoq.com/cn/news/2009/08/CRUDREST

REST构架风格介绍之一：状态表述转移

http://www.cnblogs.com/weidagang2046/archive/2009/05/08/1452322.html

思路决定出路！

        目录： 

    封闭式开发小记(1)：封闭式开发的基本装备

   封闭式开发小记(2)：封闭式开发的时间安排

   封闭式开发小记(3)：封闭式开发的人员配备

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

   封闭式开发小记(5)：封闭式开发的敏捷开发

   封闭式开发小记(6)：封闭式开发的文档管理

   封闭式开发小记(7)：如何和谐沟通、提高士气（结合开发实际冲突来深入讨论合作与沟通）

   封闭式开发小记(8)：封闭式开发的项目讨论(10.9)

   封闭式开发小记(9)：封闭式开发的最后一天(10.10)

   封闭式开发小记(10)：封闭式开发的项目汇报(10.11)

   封闭式开发小记(11)：封闭式开发的测试发布(10.12)