周日的早上&＃xff0c;今天不打算出去了&＃xff0c;昨天还是阳光明媚的&＃xff0c;今天就起风了。窝在家里看电影了。
上篇关于代码组织呢&＃xff0c;谈了一点自己对分层和代码模块化的想法&＃xff0c;这篇呢&＃xff0c;想分享一些业务逻辑切分&＃xff0c;缓存和面向服务三个方面的想法。
业务逻辑切分
1&＃xff0c;给业务定逻辑
接触一个项目首先是想怎么将业务整理清楚&＃xff0c;小型项目其实和大型项目的基础逻辑大体一样&＃xff0c;只是颗粒更少一些而已&＃xff0c;经常会发现以为接过来的是个小项目&＃xff0c;简单的业务&＃xff0c;做起来时跟大项目的逻辑差不了多少。这里呢&＃xff0c;以一个常见的视频站点系统来做例子说明&＃xff0c;通常&＃xff0c;一个视频站点最少具备一下几个功能&＃xff1a;
上传、编辑、观看、评论、下载等等
如果细分的话&＃xff0c;加上删除&＃xff0c;和用户管理&＃xff0c;会有很多逻辑&＃xff0c;怎么归类整理呢&＃xff0c;我们常见的做法是“面向对象”&＃xff1a;
视频&＃xff08;上传&＃xff0c;编辑&＃xff0c;删除&＃xff0c;下载…&＃xff09;
用户&＃xff08;注册&＃xff0c;登录&＃xff0c;管理…&＃xff09;
评论&＃xff08;发布&＃xff0c;编辑&＃xff0c;删除…&＃xff09;
这里仅做简单抽象&＃xff0c;为什么要这样抽象出来呢&＃xff1f;所谓的面向对象&＃xff0c;个人认为就是在一堆业务中找到行为实体及实体之间的关系。要想理顺一堆关系&＃xff0c;就要找到这堆关系中都有谁&＃xff0c;谁跟谁之间产生联系&＃xff0c;首先我们得找到这个行为的个体&＃xff0c;这是生活中的积累下来的解决问题的逻辑&＃xff0c;同样适用于软件开发。
2&＃xff0c;代码切分业务
在上面的视频站点功能和业务清楚之后&＃xff0c;我们需要的是定数据结构&＃xff0c;定数据结构的时候&＃xff0c;会发现找到的这些实体&＃xff0c;让数据结构变的更为简洁&＃xff0c;如果是按照网站的功能划分呢&＃xff1f;视频上传、用户观看、评论、下载、删除等等&＃xff0c;数据结构设计起来可能就无从下手了。
有了基本的实体&＃xff0c;我们可以使用面向对象的方式&＃xff0c;对每个实体进行一些CURD的操作&＃xff0c;并且可以通过关联的方式让他们产生联系&＃xff0c;那么代码中就会有几个基本的组成
a,实体的CURD
b,实体事件关系的处理
c,其他站点功能的实现
从这三个方面去组织代码&＃xff0c;可以相对比较清晰的去完成站点的代码编写工作。
缓存
最近一段接触了一些缓存的问题&＃xff0c;好处大家都知道&＃xff0c;大大提高了效率&＃xff0c;但是也有缺点&＃xff0c;这里举例说明。我的应用中有好几个层&＃xff0c;其中有两个层呢&＃xff0c;可以简单的比作客户端和服务端&＃xff0c;我们经常需要在服务端做缓存&＃xff0c;大体有集中缓存方式&＃xff1a;
a,自定义代码实现缓存
b,利用.net自己的缓存机制
c,利用memcached等第三方的缓存组件
可是几乎所有的项目都不会是那么简单的&＃xff0c;缓存有点就有缺点&＃xff0c;实时性怎么样&＃xff0c;如何更新缓存&＃xff0c;怎么实现同步等等&＃xff0c;最近的一次关于缓存的经历是silverlight端经常需要加载所有用户&＃xff0c;这导致整个RIA在客户端的运行速度巨慢&＃xff0c;我们于是就在服务端和客户端都加入了缓存机制&＃xff0c;简单说明一下&＃xff1a;
当应用程序开始运行时&＃xff0c;将所有用户加载到服务器缓存&＃xff1b;
用户登录&＃xff0c;从服务器下载所有用户到本地缓存&＃xff1b;
当有用户更新信息到服务器&＃xff0c;服务器随即更新服务器缓存&＃xff1b;
服务器更新缓存后&＃xff0c;利用回调机制将各个客户端缓存的信息更新。
您瞧&＃xff0c;我这里还只是个简单的需求&＃xff0c;实际应用中的缓存处理比这个还要复杂的多&＃xff0c;需要针对不同的情况采用不同的方式。
面向服务
这也是个大话题&＃xff0c;提到服务很容易就想到了webservice,soap,wcf等等&＃xff0c;其实&＃xff0c;面向服务不仅仅是这样&＃xff0c;我们的代码也可以是面向服务的&＃xff0c;比如业务逻辑的代码&＃xff0c;既可以服务webform,也可以服务winform.
京公网安备 11010802041100号