关于代码组织的一些看法（下）

周日的早上，今天不打算出去了，昨天还是阳光明媚的，今天就起风了。窝在家里看电影了。

 

上篇关于代码组织呢，谈了一点自己对分层和代码模块化的想法，这篇呢，想分享一些业务逻辑切分，缓存和面向服务三个方面的想法。

业务逻辑切分

1，给业务定逻辑

接触一个项目首先是想怎么将业务整理清楚，小型项目其实和大型项目的基础逻辑大体一样，只是颗粒更少一些而已，经常会发现以为接过来的是个小项目，简单的业务，做起来时跟大项目的逻辑差不了多少。这里呢，以一个常见的视频站点系统来做例子说明，通常，一个视频站点最少具备一下几个功能：

上传、编辑、观看、评论、下载等等

如果细分的话，加上删除，和用户管理，会有很多逻辑，怎么归类整理呢，我们常见的做法是“面向对象”：

视频（上传，编辑，删除，下载…）

用户（注册，登录，管理…）

评论（发布，编辑，删除…）

这里仅做简单抽象，为什么要这样抽象出来呢？所谓的面向对象，个人认为就是在一堆业务中找到行为实体及实体之间的关系。要想理顺一堆关系，就要找到这堆关系中都有谁，谁跟谁之间产生联系，首先我们得找到这个行为的个体，这是生活中的积累下来的解决问题的逻辑，同样适用于软件开发。

2，代码切分业务

在上面的视频站点功能和业务清楚之后，我们需要的是定数据结构，定数据结构的时候，会发现找到的这些实体，让数据结构变的更为简洁，如果是按照网站的功能划分呢？视频上传、用户观看、评论、下载、删除等等，数据结构设计起来可能就无从下手了。

有了基本的实体，我们可以使用面向对象的方式，对每个实体进行一些CURD的操作，并且可以通过关联的方式让他们产生联系，那么代码中就会有几个基本的组成

a,实体的CURD

b,实体事件关系的处理

c,其他站点功能的实现

从这三个方面去组织代码，可以相对比较清晰的去完成站点的代码编写工作。

缓存

最近一段接触了一些缓存的问题，好处大家都知道，大大提高了效率，但是也有缺点，这里举例说明。我的应用中有好几个层，其中有两个层呢，可以简单的比作客户端和服务端，我们经常需要在服务端做缓存，大体有集中缓存方式：

a,自定义代码实现缓存

b,利用.net自己的缓存机制

c,利用memcached等第三方的缓存组件

可是几乎所有的项目都不会是那么简单的，缓存有点就有缺点，实时性怎么样，如何更新缓存，怎么实现同步等等，最近的一次关于缓存的经历是silverlight端经常需要加载所有用户，这导致整个RIA在客户端的运行速度巨慢，我们于是就在服务端和客户端都加入了缓存机制，简单说明一下：

当应用程序开始运行时，将所有用户加载到服务器缓存；

用户登录，从服务器下载所有用户到本地缓存；

当有用户更新信息到服务器，服务器随即更新服务器缓存；

服务器更新缓存后，利用回调机制将各个客户端缓存的信息更新。

您瞧，我这里还只是个简单的需求，实际应用中的缓存处理比这个还要复杂的多，需要针对不同的情况采用不同的方式。

面向服务

这也是个大话题，提到服务很容易就想到了webservice,soap,wcf等等，其实，面向服务不仅仅是这样，我们的代码也可以是面向服务的，比如业务逻辑的代码，既可以服务webform,也可以服务winform.