这里主要简单介绍一下我们产品中主要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
思路决定出路!
目录:
封闭式开发小记(7):如何和谐沟通、提高士气(结合开发实际冲突来深入讨论合作与沟通)
封闭式开发小记(8):封闭式开发的项目讨论(10.9)
封闭式开发小记(9):封闭式开发的最后一天(10.10)
封闭式开发小记(10):封闭式开发的项目汇报(10.11)
封闭式开发小记(11):封闭式开发的测试发布(10.12)