三层最重要的也是“抽象”

　　只用class的，那叫做“基于对象”，比如当初的vb6.0；只是分了三个项目，把以前写在一起的代码分成了三份，所谓的业务逻辑层就是一个传声筒，这一类自称三层的，在我看来都是“模仿三层”，甚至是“伪三层”。

　　面向对象，就是要先考虑“对象”，考虑对象的时候完全不用去考虑数据库结构是什么样子的，这个对吧？ORM讲究的是现有O后有R，然后再去映射。

代码

　　写到这里，突然想到一个观点：其实O和R是同时有的，他们都是根据项目需求来分别设计的，互不影响！都设计好了之后再去考虑如何映射。

　　您可能会说，都分别设计，那么设计之后还能对应上吗？关于这个问题，本来对象和关系型数据库的思路就是完全相反的。

　　面向对象，考虑的是对象，抽象，个体。要把众多的对象抽象出来，要把众多的属性、方法整合起来，要把各个类找到适合的关系。

　　关系型数据库，考虑的是划分，做到数据尽量没有冗余，那么多的范式要达到的效果是什么？就是要尽量的分表，分成多个表，每个表只表达一种意思，然后在“关系”（关联）在一起，以达到避免数据冗余的目的。

　　面向对象是根本就不去考虑数据冗余的问题的，他考虑的是“一”。一个对象的结构，和其他对象的关系（继承、接口、委托、组合、聚合等）。他不会考虑一万个实例会如何，至少不会把这个当成重点来考虑。

　　关系型数据库考虑的是“多”，多条数据，一万、十万、百万条记录，要如何处理。多条数据如何处理的问题。

　　好像有点跑题了，赶紧回来。

　　上一篇，写的那种“分开”方式，为了三层而三层的做法，我觉得就是伪三层，所以请注意，我说的是伪三层不好，为了三层而三层是不对的。我觉得我上一篇写代码的方式根本就不是真正的三层，所以请大家不要误会，我并没有说真正的三层不好，我也不是反对面向对象。

　　这一篇我就是想说一下，我使用面向对象的方式。也许我的思路和您的理解不大一致，不过没关系嘛，拿出来大家一起讨论嘛。

　　网站，从业务方面（就是客户的需求）可能的分类形式，比如博客园

　　一开始博客园并没有这么多的模块，后来慢慢加上去了。那么我们是不是要按照这些分类来设计类呢？一个模块一个类或者若干个类？如果简单的这么做的话，那么就是类爆炸！而且没有进行抽象。（我不知道博客园是怎么做的，这里只是猜测，从技术角度上的猜测。我只是那大家熟悉的来举个例子，请不要联想，谢谢。）

　　我作网站的话，会从另一个角度来思考 —— 从页面的角度来分类

　　可能您看着有点晕，这都什么呀，乱七八糟的，先不要着急，带我慢慢道来。