Stella 知识库--层模式及组件编程

-- 系列文章与Stella Forum v2.0搭配使用效果更好 --

三层架构
sf2的架构还是经典的三层架构：底层的数据操作层，中间的业务层操作和呈现给用户的界面层。
所谓“层”这个词是一种架构模式。或许这个词太抽象了，我们考虑一个现实世界的情况：假设你去商店买东西，你只是和售货员交互，你永远也见不到生产这个商 品的厂商的人。这样售货员就只管卖东西，她（为什么是她？）后面有采购员负责和厂商打交道，他（他！）也不需要知道该如何卖东西，最后厂商只要做好生产就 可以，最终卖给客户的事他们也不需要管。这叫做社会分工好处是大家都职责明确，不用被过多无关的事情所困扰。当然在现实社会中，这种绝对的分工是不可能存 在的，但是在软件的世界中却需要这种绝对的分工。好处是可以降低耦合、增加系统的柔韧性等等等……
我们的表示层的作用是和用户的操作产生可见的交互，比如呈现数据，比如收集数据。那要呈现的数据是怎么组织的？数据收集过来后该怎么处理？这些问题的解决 都在业务层。（关于业务这个词大家理解吗？我第一次见的时候都不理解，这个层可以说成“数据处理层”“事情处理层”等其他名字，我猜业务这个词是从 business这个词直译过来的……）业务层不辞辛苦的把事情都做完了，就需要把数据保存到一个持久地东西里，这就需要数据操作层，在那里，数据或许被 存到数据库，存到xml文件，存到上衣的口袋……到底怎么存的业务层就不用管了。总之业务层知道当他（！）需要数据的时候数据层肯定可以给他。同样表示层 也不用管她（！）呈现给用户的数据经过了怎样的处理，她只管展示。
上面说了这么多，其实都是我自己的理解，大家如果不明白，可以去查一些大部头……
下面是对我的这个系统的分析。
表示层由web 和 WebComponents这两个项目组成，其中WebComponents里放的是一些自定义控件，这些控件都用在web里的页面中。
业务层由Business和 Rules这两个项目组成。Rules里存放的是一些验证规则，其实这两个本来是放在一个项目中，只是后来Rules里面的东西越来越多，我才决定把这个独立出来。
数据层则是最后面的SPLDAL 和SPLEntity这两个项目。
大家注意了，在业务层和数据层那里有个Factory层，这个主要是起隔离作用，这样在你更换数据层的时候就不会影响到上面的部分，因为业务层总是和Factory打交道。

组件的使用
基本的架构就是这样，但如如果只有这三个层，系统还不能运转。 需要考虑的事情还有：层间数据的传递，通用操作的复用，系统参数的设定，这些绝对不能和层耦合到一起，最好的做法是分开来，将他们转化成组件。
明显的就是工具组件的出现，这种包括程序调试、安全操作等多任务集一身的组件很容易的得到复用。
而读取系统设定的操作我也单独拿出来放在一个组件里，这样其他的组件就不要去担心设定的问题。直接拿来用就可以。
最后要解决的问题是，数据如何在层间传递，这个本身就可以另写一篇文章，因此在这里就不多说了。